Is Scaling Agile an Oxymoron?
Agile methods were designed for and are most successful in small software development teams—that is their sweet spot. But the success of agile methods has meant that larger projects and programs also want a share of the benefits that can come from focused and cohesive teams delivering fast-paced incremental solutions.
As a result, there are ongoing attempts to scale agile methods, most notably Disciplined Agile Delivery (DAD), and more recently the Scaled Agile Framework (SAFe). Both of these processes attempt to “thread the needle” and find a delicate balance between agility and the more traditional plan- and architecture-driven approaches that larger organizations favor.
But as compelling as the idea might be, is scaling agile an oxymoron? Isn't it contradictory to expect large and complex projects to somehow be agile when agile methods rely on informal communications, emergent design, and cohesive, ideally collocated teams? Should we expect such approaches to scale, or would such an attempt inevitably lead us back to big, bad waterfall thinking?
Ken Schwaber, the creator of Scrum, recently presented his unfiltered view on SAFe in a blog post he scathingly titled "unSAFe at Any Speed." His key points seem to be that he does not like any formulaic approach to development and considers SAFe to be a throwback to the bad old days.
But now that the war for hearts and minds has been largely won, I would wish agilists could be more accepting of new approaches and alternatives. There is a danger if agile—or, more specifically, Scrum—sees itself as the new “establishment” and goes “protectionist” and attempts to shut down what could be a valuable and healthy debate.
I am not advocating DAD or SAFe or any other attempt at scaling agile methods. In terms of the SAFe-Scrum debate, there are plenty of views in favor of Scrum or of SAFe. What I appreciate is the attempt being made to bridge the camps, even if I think there is yet more to be done.
The debate is an echo of the “method wars” of the past, and the real takeaway is that two camps still exist—period. This methodological tension is the challenge we face in embracing both change and complexity, and the answer may need to go beyond simply scaling what works in small development teams. As Ken states, there is clearly no one-size-fits-all approach that suffices, and we need to keep the values and principles of agile and be empowered to think for ourselves.
Sometimes, to remain agile, our methods need to adapt.
