Alternatives to the ‘big’ frameworks
After the aforementioned “big three” and the work of LeadingAgile come a host of smaller scaling frameworks and methods. Sam Laing’s Scrum Lean in Motion (Slim), for instance, is designed to complement LeSS. This author is the creator of Sustainable Cultural Agile Release in the Enterprise (SCARE), which applies the theory of constraints to agile adoption and is based on patterns that have emerged from successful scaling projects. Ron Quartel’s FAST Agile, recently announced at the Agile Roots conference, focuses on improving the integration speed of large groups (and reducing waste) through the use of near-continuous open space meetings for planning.
If you could think of managing a large IT organization as one portfolio of work as a kind of scaling, then another option to consider is Johanna Rothman’s work on The Project Portfolio and Program Management.
What the scaling frameworks are missing
Adam Yuret, a portfolio management and strategy consultant, points out that the scaling frameworks cannot prevent a senior executive from personally poring over specifications and bug lists. He adds that “Not only is that not the best use of their time, but when you have that as an example, it leads to middle-management doing the same thing, which eventually ends up with programmers getting conflicting directions from multiple people.” Yuret’s fix is not a framework, but strategy deployment, where leadership communicates clear strategic intents, then trusts the teams to deliver on that strategy however they see fit.
A few other leaders, including Arlo Belshee, Matt Barcomb and Alistair Cockburn, have gone on to propose alternatives to the “scaling framework” idea.
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.”
Sign up for Computerworld eNewsletters.