Agile, to Scale

By 

Bill Krebs, PMI-ACP

As agile matures, it's being employed at the program level by larger teams, many of which are broken down into groups. How must agile evolve to match these growing needs? In this first of two posts, we will look at some of the key objectives of the agile approaches designed for large-scale projects. 

Scott Ambler's Disciplined Agile Delivery and Dean Leffingwell's Scaled Agile Framework are two such approaches. These in particular reevaluate some concepts from the IBM Rational Unified Process framework. Among the most useful concepts shared by all three is the opportunity for teams to balance upfront planning needs while preserving agile's ability to refine the plan based on empirical observation of real results. All also speak more to what architectural underpinnings are necessary to give larger teams a firm foundation:

1. Feedback through iterations
2. Technical practices to build in quality
3. Lean thinking to optimize the overall system

In larger teams, agile approaches -- such as the feedback afforded by iterations in Scrum -- remain popular, as do the technical practices centered around quality. Lean principles used by smaller agile teams remain important to reduce wait time, optimize the entire system and balance flow among teams. But the frameworks mentioned above also add a fourth dimension: synchronized relationships among agile teams. In particular, aligning teams so their sprints end at the same time is useful, because it facilitates the release of the product.

So what's different for large teams trying to use agile methods? First, overall investment governance becomes all the more important. Larger projects require more preparation to justify the greater levels of funding. They also may have more complicated dependencies among teams. Organizations will need to find a way to allocate effort between work in their portfolio of projects. This includes not only features, but also infrastructure work and nonfunctional requirements. And organizations should also use investment gate models to ensure funds are invested wisely.  

Second, technical architecture is also very important. In smaller agile teams, people may experiment first and then evolve guidelines and patterns. But in larger teams, overall design and architecture plays a leading role so as to better coordinate among teams. System teams, or people who work on supporting teams creating features, also become important as the demand for a shared infrastructure increases.

Finally, metrics quickly become important. New metrics -- designed specifically for larger teams -- provide a holistic view of the overall health of the large team, and also help gather and assemble data for the smaller groups within. This allows organizational leaders to see, at a glance, where the overall program stands, so they can make broad project decisions with wide impact.

These general principles guide many methods to scale agile from teams of seven to 100 members. In my next post, we will look at some specific practices to enable large teams to find the benefits of agile.

What do you think are the fundamental principles of scaling agile?