significant undertaking that involves resources from other teams and other departments. Achieving ready feedback pushes all these teams to smaller and more frequent releases. At enterprise scale, release cycles typically move from as long as 12 to 18 months to as short as three to four months. Again, while not a trivial undertaking, once mastered, the teams become addicted to the faster cycle of market feedback and often push for faster and faster releases to help them evolve their products more quickly.
4. Two-level planning. While agile eschews detailed up-front, long-range planning, a subtle fact is that agile is a very disciplined and (yes, even) planned process that simply breaks the planning cycle into shorter chunks (in a manner similar to building software in smaller iterations). Two types of planning occur. At the release level, which is the preparation for deployment and/or shipment to end users, application or product roadmaps define a series of releases that are sketched out using "broad brush strokes": themes and high-level features , based on a prioritized backlog (a list of things the application needs to do.) At the iteration level, which is a shorter, time-boxed increment of new functionality, more detailed planning occurs. Iteration planning breaks the objectives of the iteration into smaller tasks typically of no more than a day or two. This improves estimating and helps the team more readily achieve their commitment to the iteration. Together, these two types of planning provide the long and short view necessary for the enterprise to communicate its objectives to both the project team and to its executive stakeholders and customers.
5. Concurrent testing. In agile, all code is tested code . There is no other kind. No longer do the developers create "mounds of theoretical working code" as testing is integral to the development process. Unit testing, acceptance testing, and performance and reliability level testing are driven to occur inside each iteration . In some agile models, such as XP and Test Driven Development, the teams are encouraged write the test first in which case the test also serves as a ready proxy for the system requirements, but a proxy that persists in the future as regression tests to continually assess readiness of the code as the solution evolves in future iterations.
6. Continuous integration. Another roadblock on the way to the agile team's performance is the necessity of continuous integration. Like many of the practices we described above, continuous integration is not new and has been applied by many teams for some time. At scale, however, continuous integration has created challenges as it can be difficult to assemble changes from a large number of components daily, create an adequate build environment, and to automate the tooling necessary to integrate, build and perform "smoke tests" frequently. In agile, this roadblock cannot stand. For example, I witnessed one team of approximately 300 people building a large-scale systems infrastructure application reduce the integrate-build-regression test cycle time from a month to less than a day . Initially, these teams were intimidated by the objective but as their agility increased, they recognize this bottleneck to productivity and correspondingly increased their resources and focus on this key activity. They are software professionals after all and this is a software problem.
7. Regular reflection and adaptation. A key agile manifesto principle ( http://www.agilealliance.com/) is "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." In agile, this key practice is truly "the gift that keeps on giving" as the empowered, agile teams naturally address and eliminate