Part II of II - Seven Additional Practices For Enterprise Agility
In part I of this Article, we noted that the benefits of agile software methods, including faster time to market, better responsiveness to changing customer needs and higher quality are undeniable to those who have mastered these practices. However, these practices have been developed and refined in circumstances characterized by small, co-located teams with ready access to a customer. Can enterprises building applications that require hundreds of distributed team members benefit from these practices, or are they forever doomed to large, late, stage-gate and waterfall-like results?
Indeed, many larger enterprises have demonstrated that they can benefit from application of agile principles. In Part I of this article, we described seven best practices of agility that natively scale to the enterprise level: Iteration foundation, the definebuildtest component team, smaller and more frequent releases, two-level planning, concurrent testing, continuous integration, and regular reflection and adaptation. In {sidebar id=1} Part II, we'll describe an additional set of seven organizational best practices that a company can master to achieve even more of the benefits of software agility, especially for large distributed teams.
Seven Agile Enterprise Practices: Scaling Agile Across Large and Distributed Teams
The seven team practices alone do not fully address all the issues necessary to achieve software agility at enterprise scale. Achieving that requires work in seven additional areas:
1) Intentional architecture. For small, agile teams that can define, develop, and deliver a product or application that does not require much coordination with other components, products, or systems, the basic agile methods will produce excellent results. But what happens when these teams must coordinate their activity as their components integrate into subsystems which in turn, integrate into larger systems? Moreover, refactoring of these larger scale systems may not be an option as many hundreds of person-years have been invested and the system is already deployed to tens of thousands of users. For these systems, the agile component teams have to operate within the context of an intentional architecture, which typically has two key characteristics: 1) it is component-based, each component of which can be developed as independently as possible and yet conforms to a set of purposeful, systemically defined interfaces; and 2) the components themselves are well-aligned with the teams' distribution so that the individual teams can work as autonomously as possible. (If this is not the case, it is likely that the teams will have to be realigned thereto!).
2. Lean requirements at scale: vision, road map and just-in-time elaboration. The most agile teams use their ability to code quickly and efficiently as a requirements discovery process and avoid the overhead of formal specifications. This can work effectively as a small team can write and rewrite code at a rate faster than many organizations can attempt to determine and codify their customer requirements anyway! At scale, however, the challenge changes and certain requirements, such as those that define the performance, reliability and scalability of the system, must be understood by all teams, and relatively early on. And yet, this must be done while the investment in early requirements definition is substantially reduced. To this end, a number of larger-scale agile teams have converged on a lean requirements pattern that has three main elements: avision, a roadmap, and just-in-time requirements elaboration.
The vision carries the common objectives for the teams and serves as a container for key non-functional requirements that must be imposed on the system as a whole. The roadmap illustrates, in very broad-brush strokes, how that vision is to be implemented over time in accordance with a prioritized backlog. Just-in-time requirements elaboration defers specific requirements expression until the "last responsible moment," eliminating the waste and scrap of overly detailed, SRS-like (software requirements specifications) documents that are never implemented do to changes in scope and direction of the project over time.
3. Systems of systems and the agile release train. Simply put, agile teams create more product more quickly and coordinating delivery of these products to the market becomes an enterprise challenge. The principles of lean manufacturing and lean and concurrent product development drive many aspects of agility. They also drive teams to the conclusion that product releases, like new cars or new widgets for the holiday season, must be coordinated and integrated on a fixed, inviolate schedule - a release train - where dates are fixed, themes are fixed, and quality is fixed.
If all the above are fixed,functionality must then be variable but the software train must leave the station on time. Mastering the skill can be a challenge for the enterprise, but once in place, the enterprise can leverage the ability of teams to create to create smaller and more frequent releases with an ability to coordinate those releases to create substantive market or customer impact.
4. Tooling the agile enterprise. Smaller component teams that require little coordination with other teams may require little tooling. Larger teams require relatively more tooling and at the enterprise level, a more systematic approach is required. Enterprise-level tooling must support the 7x24 multi-site communication and integration challenges present in larger and distributed organizations. This challenging communication environment needs shared, program-wide visibility into priorities, real-time status and signaling, dependencies and "blocks" for tight coordination across geographies and time zones. Teams must have access to networks and Internet-based tools that enable shared repositories for agile project management, shared requirements, source code management, common integrated build environment, change management and automated testing.
5. Changing the Organization. Agile methods drive substantial change in the organization. In addition to the challenge of rolling out agile methods across hundreds and thousands of developers, the team's constant search for improvements will readily identify organizational roadblocks, bottlenecks and impediments that limit productivity. These may include impediments such as insufficient resources for testing automation and system-level testing, slow and cumbersome interfaces to product management and/or customers that prevent rapid feedback on iterations and progress, and more. Sponsoring executives must be willing to provide the training and support necessary as well as be ready to foster the necessary changes at the organization level.
6. Impact on customers and distribution. While it is easy to say "smaller and more frequent releases," it is not so easy to do. And, even when the local teams accomplish this feat, the enterprise's job is not yet complete. The availability of more code-more quickly will affect the end user community and those who interface to it. This may require more intense coordination and closer communication as to the actual progress towards the release train objectives. For example, for those enterprises who sell software to others, sales and marketing teams are key stakeholders of the delivery process. Those teams will also have opinions about the delivery challenges and incorporating their input and assuring their involvement in more rapid delivery is essential to achieving optimal results.
7. Measuring business performance. At the team level, agile project measurements are relatively straightforward. Thankfully, the existence of actual working code on a more frequent basis is the primary measure of productivity and all other measures are secondary. And yet with most enterprises, this fact alone will not necessarily meet the need for additional, company-wide performance measurements. In that case, performance measures must also be built to help the executives understand where they are in their goal of continuing improvement and where additional improvements need to be made.
Fortunately, agile is very measurable and measurements such as "% stories completed per iteration" and "feature or customer value points delivered" are easy to capture at the team level. Aggregating these measures across teams, departments and business units and combining them with other revenue, cost or productivity measures can give the enterprise the tools it needs to assess and improve its overall business performance.
Conclusion
The seven agile team practices that scale and the seven agile enterprise practices that can be mastered will substantially improve the performance of the software enterprise. While the undertaking is significant, the rewards are significant as well, and the benefits of higher productivity, improved time-to-market, higher-quality and lower support costs, coupled with unleashing the creative and productive power of empowered project teams, will launch the company toward it's goal of a creating the agile enterprise.
About the Author Dean Leffingwell is a software industry executive, entrepreneur, and part time methodologist/author who has spent his career trying to help software teams achieve their goals. He is the former founder and CEO of Requisite, Inc. makers of RequisitePro, and a former SVP at Rational Software. He now serves as a consulting methodologist to Rally Software and as advisor to a number of larger software enterprises. He is the lead author of the text: "Managing Software Requirements: A use Case Approach", Addison Wesley, 2003. This article is excerpted from his next book entitled; "Scaling Software Agility: Best Practices for the Enterprise", scheduled for publication in fall of 2006 from Addison Wesley.
