Who needs a scaling framework anyway?
In 2008, Arlo Belshee won the Godon Pask Award, the official award of the Agile Alliance for contributions for the practice. After earning the Pask Award, Belshee moved on to a coaching/teaching position at Microsoft. That experience informed his 2013 blog post, Scaling Agile the Easy Way, in which Belshee claims that scaling objections have it backwards; that when companies develop true multi-disciplinary teams that can regularly ship software, the problems go away. As Belshee explains it, this is what happens once teams have that competence:
“There won’t be technical dependencies between your teams. Each team will be able to deliver value to the customer. Teams won’t cause problems when they integrate code with each other. None of the products will have bugs (well, not for more than about an hour out of every 2 weeks). Teams can work together in order to provide solutions that enhance each other. Teams can also deliver business value without coordinating with any other team.”
Belshee is not alone.
Matt Barcomb, an independent Agile coach and former VP of product development for Taxware, points out that while the problem of “scale” sounds hard, it typically means one of three things: spreading, coordination or alignment. As Barcomb explains it, what we think of as the big, organizational problems are fairly easy to understand:
“They are either having some success in one area and need more teams to be successful (spreading); or they have a large multi-team project problem (coordination) which is addressed with concepts from Rothman’s books or portfolio kanban and flow-based roadmaps, or else senior leadership is frustrated because through middle management down to teams don’t seem to be getting traction on the goals/KPIs they want (alignment). They typically introduce more controls, more detailed processes and more measures [“frameworks”] that typically result in the exact opposite.”
Barcomb’s approach, like LeadingAgile, is to identify where the gap is and to work on that, making small improvements to skill and culture along the way.
Finally, we have Alistair Cockburn, who organized the Snowbird Conference that created the Agile Manifesto, and was known as one of the leading thinkers on the topic before and after that conference.
Initially hesitant when approached about scaling agile frameworks, Cockburn went on to talk about something he called the "Heart of Agile.” In a nutshell, at the enterprise level, the heart of Agile asks these questions:
- Independent of anything else going on, how will you increase collaboration?
- Accounting for everything else going on, how can you increase trial and actual deliveries to consumers?
- How will you get people to pause and reflect on what's happening to and around them?
- What are some experiments your people will do at different levels in the organization to make a small improvement?
These questions are designed to help an organization decide which small change to make next in the pursuit of Agility, and to ground that change in the context of this organization and this moment, instead of relying on someone else's revealed wisdom. In short, they focus on responding to change instead of following a plan.
Cockburn subsequently elaborated on his blog with a post titled Using the Heart of Agile on the problem of scaling.
Putting it all together
The dominant framework, SAFe, provides a way for a large IT group to organize itself as teams of teams of agile teams. LeSS does the same by focusing on improving communication between the teams. Belshee suggests starting by making high-functioning Agile teams that can ship working software on demand, and the scale problems disappear, while the other consultants tend to recommend small changes to adapt an organization toward a more Agile ideal.
Once we dig past “scale” to the real problem your company is most interested in solving right now, then one of these solutions might make more sense than the others.
This story, "Scaling agile frameworks: A comparison" was originally published by CIO.