When agile software development went mainstream several years ago many agilists declared success. It clearly was a success, but only one of many. Recently I’ve been seeing more and more organizations attempt to apply agile strategies in what I would consider scaling situations for large teams, on geographically distributed teams, or in regulatory environments for example, and I predict that this will continue for several years to come. Why? First, agile strategies not only work better in practice than traditional strategies they also appear to work as well or better in scaling situations as well. Second, as organizations experiment with applying agile at scale they will observe that they’re succeeding and choose to continue with tailoring agile to meet their needs.
This begs the question how do you go about scaling agile in practice, and this is where the Agile Scaling Model (ASM) comes in to play. The ASM is a contextual framework which defines a roadmap to effectively adopt and tailor agile strategies to meet the unique challenges faced by a system delivery team. Mainstream agile development processes and practices, of which there are many, have certainly garnered a lot of attention in recent years. They’ve motivated the IT community to pause and consider new ways of working, and many organizations have adopted and been successful with them. However, these mainstream strategies, such as Scrum or Agile Modeling (AM), are never sufficient on their own – as a result organizations must combine and tailor them to address the full delivery lifecycle. When doing so the smarter organizations bring a bit more discipline to the table, even more so than what is required by core agile processes themselves, to address governance and risk.
The first step in scaling agile approaches is to move from partial methods to a full-fledged delivery process, examples of such include Disciplined Agile Delivery (DAD) and Harmony/ESW – the DAD process framework focuses on information technology (IT) projects whereas Harmony/ESW focuses on systems engineering projects. These methods provide end-to-end advice, from project initiation to releasing your solution into the marketplace, for applying agile strategies effectively. Disciplined agile methods explicitly include agile/lean governance strategies which enable them to work within the overall IT organizational ecosystem. Finally, disciplined methods explicitly go beyond the narrow focus of software to address solution delivery, which includes software, hardware, business process improvement, organizational improvement, and other important issues. Agile applies to far more than just software development.
To get a feel for what I’m getting at, compare the Scrum construction lifecycle of Figure 1 with the DAD lifecycle of Figure 2. You can see how the DAD lifecycle extends the Scrum lifecycle to address the full solution delivery effort. I’ve run into numerous organizations around the world that have developed something very similar to Figure 2, yet it’s been very rare to find organizations that thought to go looking around on the Web for this sort of thing. Regardless, I think it’s fairly safe to predict that organizations will continue to apply agile strategies across the full delivery lifecycle in 2011 and beyond, and not just to construction.
Figure 1. The Scrum construction lifecycle.
Figure 2. The Disciplined Agile Delivery (DAD) lifecycle.
Once you have experience with applying agile across the full delivery lifecycle, the second step to scaling agile is to address the degree of complexity faced by your solution delivery teams. A lot of the mainstream agile advice is oriented towards small, co-located teams developing relatively straightforward systems. But once your team grows, or becomes distributed, or you find yourself working on a system that isn’t so straightforward,