Do all scaling frameworks just suck?
There’s a lot of backlash about frameworks. I say that, but I think the Scaled Agile Framework (SAFe) probably bears the brunt of it all. Right? LeSS, Nexus and Scrum at Scale are basically extensions of Scrum. And while I know Scrum has its detractors, it’s also considered the training wheels of agile and largely accepted by our community at large. (The Annual State of Agile Report has its market share over 50% still.) Disciplined Agile isn’t really a scaling framework as much as it is a process decision framework to help with multiple aspects of an agile transformation. I bet if you were to ask your average Agile Coach for a recommendation about which framework to use to scale your agile transformation, you’re more likely to get this quote than one particular framework as their answer: “Simplicity is the only thing that scales”
The concept of simplicity is right in the Agile Manifesto 12 principles: “Simplicity — the art of maximizing the amount of work not done — is essential.” And there are a plethora of quotes around simplicity. From Occam’s Razor to Mies van der Rohe’s “Less is more”, here’s 145 quotes on simplicity for you.
But what does that mean? Simple can also mean stupid if you’re not careful. Stupid is as stupid does, right?
So when the community talks about ‘capital A’ Agile being the over-commercialized and overwrought machinations of the framework-centric agility world, I think a lot of the criticism is squarely on SAFe. There is also an excellent post on critiquing the Deloitte subway map too (shown above), which helps explain the complexity of our agile universe.
And if ‘lowercase a’ agile leans more toward common sense, being nimble and simplicity, then what is the right answer? Making a whole company agile is definitely not simple either.
Tom Gilb, who was perhaps the original agilist, has written, “If you don’t know what you’re doing, don’t do it on a large scale.” This quote sums up a lot of my own criticisms of frameworks like SAFe. Not because the framework is inherently bad, but because it’s so well-defined and structured that some organizations try to adopt too much of it at once, fooled into thinking there are silver bullets and mysticism hidden in its structure and complexity.
For me, the answer is clearly somewhere in the middle, which I also realize is vague and not much help. The lesson is not in adhering to anything wholesale, nor giving up on structure, but instead finding the meaningful constructs given your context and capabilities that work for you at a given time and the rigor and courage to inspect and adapt to readjust as you make progress.
And while an organization learns to make progress at the product team level and grows to many teams of teams, that type of success can only go so far. One is still stuck with “agility only scales to the level that management supports”. The challenges of scaling agile are therefore often with top-down executive support and in growing agility outside of technology. These challenges are only solved by senior executives driving agility, Finance and HR driven agility themes, and eliminating cultural boundaries between technology and the business. Which, ironically, brings us right back to SAFe. For any company-wide transformation to be successful there must be great progress in all three layers: Team, Program and Portfolio.
So, my advice is to be patient with your transformations and work hard to get comfortable scaling organically with common sense and whatever structure works for you to get to multiple products and teams of teams. And as soon as your company and its culture is able, find the strategies that allow you to also make progress on the Portfolio and Program levels. Hidden in those upper two levels, and rarely called out specifically by frameworks, is the massive amount of work to transition middle management into the servant leaders that the product teams require. Especially challenging is the awkward need to keep the old way of working alive with traditional management structures while the new servant leadership and product-centric ones emerge.
Perhaps then the answer is both. Simplicity followed by complexity, carefully navigated so that your company absorbs and changes at the pace that works. Start with lots of little-a agile so you can build on that success with just the right amount of big-a agile later.
If you enjoyed this, please clap or share. It means a lot to know my work on this blog is read and used by agilists out there in the world.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense.
I’m writing a book and will release the first of three sections soon! It’s called MakeTeamsAwesome.com. Sign up there to be notified when it’s released.
If you’re working on a hard problem and need some help or have questions about how an Enterprise Agile Coach could help you, your teams, and your company, let me know. I’d love to hear from you, email me anytime.
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
