Scaling agile: What framework to use—and when
When Extreme Programming was created, there was one common objection: It didn't scale. The creators of XP shrugged and made it a team-level method.
Other experts, including Ken Schwaber, argued that the projects were too big and needed to scale down. Since that time, a half-dozen other methods have evolved that promise to solve the scaling issue.
When people say "the scaling problem" or "it doesn't scale," they may mean one of a number of things. Most experts agree the term involves coordinating larger groups to deliver products, or to direct those groups in a more hands-on way.
If you're deciding which agile scaling method to select, here's how to make an informed choice.
Scrum and beyond
Peter Vollmer, a distinguished technologist at Micro Focus, points out that all these frameworks are working toward the same purpose, solving the problem of inter-group coordination and collaboration.
Most of them extend the Scrum of Scrums concept, adding organizational coordination meetings for additional layers in the hierarchy. Some methods are limited to software development, perhaps adding operations. Others go beyond a product group to consider business elements such as funding, HR, and marketing.
These methods take Scrum and add another level, where each Scrum team sends a representative to the next-level meeting. The Nexus Guide (free PDF) is clearly a manual for how to make Scrum of Scrums work, with a unified backlog, an increment worked on in a single coordinate sprint, and so on.
LeSS, or Large Scale Scrum, takes the basic meetings of Scrum and then creates a higher-level daily Scrum meeting that covers planning, retrospective, and so on for additional levels. LeSS coordinates the work across all teams in a single, two-week, synchronized sprint.
Figure 1. The LeSS Framework diagram. Source: Licensed under creative commons, with attribution by less.works.
Most of the frameworks assume that the delivery team-of-teams already exists, has funding, and is pointed in a specific direction. From there, the "product owner of product owners" steers a backlog that the teams execute on.
These approaches do not consider project inception, funding, or tech support. They also don't consider outside groups that might be involved and have a different cadence, such as legal, HR, or marketing.
Finally, these frameworks assume people can figure out how to do their job. Like Scrum, LeSS and Nexus have very little to say about how to do software development, integration, or testing, preferring to create an environment for people to collaborate and share.
Disciplined Agile Delivery (DaD)
Scott Ambler, DaD's leading contributor, is well known for his work adapting the Rational Unified Process to agile software, creating the Agile Unified Process. That work added project inception, transition, and support, bringing in other groups from throughout the company.
He suggested that teams understand their own context and problems, then have some "humility" and look to the greater world for the solutions that already exist. That makes DaD a toolbox of sorts, he said, with options and tools to solve every common problem.
DaD recently joined the Project Management Institute (PMI), which published the book Choose Your WoW!, a 400-page compendium of "way-of-working" methods. A close relationship with the PMI will make the transition easier for traditional project managers.
The material as it exists now can be terse and difficult to read. It will require training. In general, expect the investment in training and coaching for DaD to be much smaller than the SAFe option.
Scaled Agile Framework
The Scaled Agile Framework (SAFe)'s lead author, Dean Leffingwell, came out of the Rational Unified Process space, as a senior vice president at Rational Software. SAFe is sort of a big box of methods. It creates a hierarchy (Scrum of Scrum of Scrum of Scrum of …) but also overlays all the support functions a team might need.
Perhaps most importantly, SAFe ties together lean methods and the theory of constraints, helping larger delivery groups find and remove bottlenecks, which can be critical to accelerating value delivery.
On the downside, SAFe is an extremely large, comprehensive framework that gives some, but very little, guidance on which pieces of SAFe are essential, what can be deferred, which pieces of SAFe solve which problems, what problems they introduce, and so on.
This leads to the criticism that by focusing on process and tools over individuals, and by having a defined plan up front, SAFe is not really agile at all. The counterargument is that SAFe is understandable and easy to adopt for organizations that are unable, or unwilling, to jump into the void. In other words, SAFe might be training wheels for agile adoption, but if it leads to better outcomes, what is so terrible about that?
That argument against SAFe can be made about DaD, LeSS, and every other model. But the alternative does not seem to be a better scaling framework. In a recent post, GeePaw Hill, an early adopter of XP, advocated against using any "scaling framework" at all.
It's worth considering what that might look like—understanding the software delivery as a system and actively managing it. That is less like following a recipe and more like from-scratch cooking.
How to manage the program
Johanna Rothman, the famed management consultant, didn't point to a framework, model, or theory. Instead, she dove into a company's organizational structure. Specifically, she advocated measuring the cycle time of software delivery and focusing on it as a virtuous metric.
If teams know how long it takes to get things done, they tend to find the largest blocker on delivery and fix it. When that happens, the bottlenecks shift. This gives management two roles: identifying the bottlenecks among teams, and facilitating conversations with other groups, such as legal, HR, and marketing.
Rothman also suggested enabling the informal networks between people, as opposed to formal hierarchies, because the former can lead to information discovery and learning. For Rothman, the Scrum of Scrums is a communication and synchronization tool, not a method to control.
Matt Barcomb, a principal strategy consultant at Industrial Logic, explained that businesses operate at different speeds at different levels. "Strategy shouldn't just be some people who lock themselves behind closed doors and congratulate themselves," he said. "The system should involve feedback units and sensing units," he said. "Align by value stream, manage cross-cutting concerns, deal with constraint management."
Vollmer talks about the same concepts in SAFe, complete with methods to ensure, for example, that the information networks survive and grow right along with formal hierarchies. With no framework, the problem may be how to get those changes to actually happen.
If you read between the lines in the advice of Barcomb, Rothman, and Hill, they all seem to suggest that the highest level of senior executives need to build a business that will serve the customer, allowing the teams to perform while synchronizing communication.
How to choose your scaling framework
The key questions are these: What level is the initiative, and what problem is it being asked to solve? Software product groups that want to coordinate multiple software teams will be well served to consider LeSS or Nexus.
If the goal is to integrate support and portfolio management, and the group wants to talk about tradeoffs and options, consider DaD. If senior management is risk-averse and just wants to "install" agile throughout IT while trying to move the business toward lean, then SAFe is for you (it is, after all, in the name).
Finally, if top business-unit management is engaged in running software development as the business, don't give them a box with things in it; instead, select top managers who will be immersed in the work of software to better serve the customer.
Somewhere in the middle is the group that just realized that software and digital assets will be the critical success factors of the business. If that's the case, the group may start with a scaling framework—with a goal of one day not needing it anymore.