Agile at Scale: 7+7 Practices for Enterprise Agility

[article]
Summary:

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

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09