Shaping an Agile process that delivers value is not a selection of prescriptive actions.  It is a conscious effort to fit and mature best practices in an environment.  Three core questions guide this process:

• What will provide sufficient completion integrity for the work we do?
• What will create meaningful transparency of the work being done?
• What are the underlying organizational constraints that will impede changes in the way work is done?  

 
Focusing on these questions allows an IT organization to master new ways of working while minimizing business disruption.

Engineering Best Practices: Integrity of Completion
One characteristic of Agile development is that it doesn't mortgage the future by deferring activities such as build, integration, and test to later stages of a project.  In Agile, these are performed as closely as possible to the moment when code is created.  Codifying success criteria in tests before executable code is written, immediately subjecting committed code to build and execution of automated tests, and pairing developers on work provides a higher degree of certainty that work committed is work completed.  As a result, when something is asserted to be complete in an Agile project, it is less a matter of opinion and more a matter of fact.

While there are a  defined set of Agile practices that engender this, there is not a prescribed set of activities to fulfill them.  A project's circumstances and characteristics will determine the extent to which each practice should be adopted.  If they are too aggressively applied, they may add little value.  If they are not aggressively applied, Agile practices may yield no demonstrable benefits.

Consider the extent to which continuous integration is adopted.  Some technologies like C++ and COBOL may not be able to support it.  Simply because they don't support continuous integration, however, does not mean that these technologies do not benefit from the adoption of Agile build practices.  There is certainly benefit in reducing the latency between code commit and build, so in these circumstances maximizing build efficiency -- even if simply a daily event -- will add value.  Tools such as CruiseControl can support atypical Agile technologies and different build cycles.

The extent to which the build is implemented as a gatekeeper of code quality also varies depending on the nature of the team.  In a large, geographically distributed team of varying skill levels, it is extremely valuable for tests and code quality analyses (using technologies such as PMD and Checkstyle) to be implemented as gatekeeper events each time code is committed.  By comparison, gatekeepers might be a waste of time in small, co-located teams, where a simple portal into build information is usually sufficient.

It may not always be desirable to target high unit test coverage.  Consider a time-constrained project in a highly dynamic business domain where requirements change often and dramatically.  In this case, quality may be a low priority relative to time and features.  High unit test coverage might be a waste of effort as a lot of code will simply be disposed.  It might be more effective to write unit tests at the most granular level of the requirements, such as for elemental calculations, and increase unit test coverage only after the domain itself is better understood.  There are also technology limitations: legacy languages do not lend themselves to unit testing.  The somewhat cumbersome mechanisms by which this can be achieved (e.g., .NET wrappers to MQ over CICS to invoke COBOL processes) suggest there is a limited amount of coverage that can be achieved.  Still, creating testable architectures and achieving some degree of unit test coverage is preferable to electing to do neither.

Clearly, there is not a universally applicable definition of specific engineering activities that enable agility.  Each are practiced to varying degrees. The extent to which they are practiced determines the degree of confidence in task completion.

Project Management Best Practices: Transparency
In conjunction with completion integrity, it is also important to know, as specifically as possible, what people are doing.  Adopting Agile engineering practices without project management practices will improve fundamental delivery quality more than it will achieve IT responsiveness.  To have greater responsiveness requires visibility into what's going on.

Agile achieves transparency through the way in which requirements are expressed, teams are organized, collaboration is achieved, and progress is tracked.  The core Agile practices that support this - story-based requirements, co-location, iterative delivery, and so forth - are themselves not turnkey to a situation, but again must be adjusted to achieve the appropriate fit for the circumstance.

Consider a geographically distributed team of several hundred people.  It isn't uncommon for a project like this to be decomposed into separate teams working in silos, instead of everybody working from the same pool of requirements.  These silos will affect how requirements are expressed: high-level business requirements may need to be fulfilled through multiple teams working on subsets, each communicating through messaging.  This does not obviate the value of introducing some degree of story-based requirements: even where there are silos, such "pseudo-stories" can allow each team to work on independent (or at least decoupled), testable requirements that can be clearly tied to business value.

Separately, consider the extent to which project management needs to be formalized.  A co-located team may benefit from the visibility of a project "story card wall" that visibly shows requirements in different stages: completed, in backlog, in-flight and on-deck.  However, a geographically distributed team makes a physical card wall impractical.  In this case, project tracking and reporting (using tools such as Mingle) give everybody visibility into project status.  The same factors affect the degree of business collaboration as well: while it is desirable to have the business co-located with the development team, geographic separation will make this an impossibility.  This does not eliminate the benefit of having business knowledge co-located, so co-locating a proxy for the business -- such as an analyst immersed in the business problem -- can yield much the same benefit.

The practice of release planning will vary dramatically depending on the environment.  A highly dynamic domain might relegate release planning to little more than an exercise of "wishful thinking."  Publishing a release plan under such circumstances can mislead all project stakeholders and undermine a team.  In this case, the XP approach of planning by "yesterday's weather" may be the safest way to manage expectations.  By comparison, release planning in a more stable domain vastly improves project portfolio management.  Not performing release planning under these circumstances can make a team appear that it is not master of its domain.

One additional situational consideration is the degree of panic in a situation.  A project in need of crisis-management due to frequent production failures or defects will benefit from the Scrum approach of a daily stand-up executed in intermediate-length (e.g. one month) time boxes.  By comparison, a customer that cannot consume frequent releases will likely benefit from consistency achieved by a series of longer iterations and release cycles more common to Agile.

All told, then, transparency is not achieved in a prescriptive set of activities, but by the application of those practices that maximize transparency given the situation.

Overcoming Challenges Versus Managing Constraints
This should not create the impression that Agile practices are a matter of picking and choosing.  There is a demonstrably synergistic benefit: when these practices are fully implemented, they yield simultaneously a high degree of both quality and responsiveness.  While the different families of Agile practices - Crystal, XP, Scrum, and so forth - offer different perspectives on how to achieve agility, they should not be assumed to be turnkey solutions.  For example, the "yesterday's weather" approach to forecasting in XP might be extremely valuable in highly dynamic domains, but the emphasis on 100% unit test coverage might may be substantially wasted effort in the same circumstance.  Similarly, adopting Scrum management without Agile engineering practices may result in project management and technical execution not being fully aligned.  Regardless the approach, a granular understanding -- and fitting -- is in order.

It must also be recognized that Agile practices can be severely compromised by accepting every constraint in an environment.  Agile practices are commonly introduced in response to an organizational challenge, such as quality, consistency, or responsiveness.  Accepting the challenge but living within constraints will yield sub-optimal results.  For example, Agile release planning assumes there is "collective code ownership:" the entire codebase is "owned" by the team.  Accepting a situation where development is done in silos can lead to "swim lanes" if managed poorly.  Especially when code in these silos is highly coupled, this can lead to dependencies that relegate Agile release planning into a Waterfall model.  Similarly, if quality assurance is a shared service bound by fulfillment from a single geographic location, it is very likely that the QA team will be overrun, unable to respond to the rate of change coming from an Agile development team.  This will completely obviate improvements to development responsiveness.

The process of taking on Agile, then, is as much fitting Agile to an environment as it is adjusting the environment to be more responsive. This might involve re-architecting an application and aggressively pairing developers to slowly widen the silos, with the intent of eliminating code specializations over time.  It might require a complete restructure of a QA department, investing in domain knowledge and technical capability both so that delivery teams are business focused, not IT practice focused.  Whatever the solution, there must be a focus on the challenge, not the constraint.  Constraints can stifle and completely undermine attempts at greater agility.

People Over Process
While Agile practices are fit into an environment, and an environment is changed to engender greater agility, process does not translate into execution.  Change in the way work is done will only succeed if the people doing the work master the change.  When mapping out an Agile process, bear in mind that individual commitment is facilitated through participation more than it is through top-down edict.  Defining the constructs of process is helpful; engaging the practitioners in that definition is essential.