It’s been 23 years since the Agile Manifesto transformed software development. Frameworks like Scrum and Kanban and other Agile practices have allowed teams to move away from rigid, linear processes to more flexible ones that focus on delivering value to customers faster.
Since then, the world of Agile has expanded in scope. It’s no longer just for small, scrappy software development teams — it’s been embraced across industries and disciplines as an innovative way of working that puts the customer first and allows teams to self-organize.. But as Agile methods are used in ever larger and more complex organizations, how or if they should implement Agile at scale has become a contentious debate.
The debate: Is Scaled Agile really Agile?
Purists believe that rigidly interpreted frameworks stray from Agile’s original intent, especially when it comes to scaled frameworks like SAFe (Scaled Agile Framework), S@S (Scrum at Scale), and LeSS (Large Scale Scrum).
SAFe in particular draws a lot of criticismbecause it’s viewed as incredibly prescriptive, heavyweight, and top-down — the opposite of what Agile values and principles are all about. Some even consider it a perversion of Agile ideals because of its command-and-control elements. Detractors argue that SAFe wraps itself in a lot of Agile terminology, but beyond the team level it’s very hierarchical.
While you may believe there’s some truth to this sentiment, SAFe is trying to solve a thorny problem: how to coordinate dozens or hundreds of teams that have to work together while still preserving autonomy at the team level. It intends to provide the structure needed for teams to collaborate, build a common understanding of the work that needs to be done, and identify cross-functional dependencies in large, complex organizations.
In my opinion, there’s no “wrong” Scaled Agile framework. Instead, it’s about finding what works for your organization. Frameworks like SAFe and others like it should be viewed as a starting point — not as an immutable, unchangeable law because there’s no single framework that makes sense for all organizations and in all contexts.
That being said, I understand the reflex to gravitate toward concrete answers. Early in my career I was the Scrum Police; I never wanted to deviate from what the framework prescribed. But over the 15 years I’ve worked in Agile, I learned you don’t have to be pedantic about the frameworks you employ. All-or-nothing implementations, where teams aren’t given autonomy or a voice to provide feedback, are the antithesis of Agile.
Scaled Agile frameworks should be flexible
Anyone who wants to implement Scaled Agile needs to approach it from an experimentation and growth mindset. If you’re not sure where to start, keep in mind the values and principles from the Agile Manifesto, which should guide any type of Agile transformation, scaled or otherwise.
With these principles in mind, think of Scaled Agile frameworks as toolkits rather than the letter of the law, selecting elements that are useful and discarding ones that aren’t. (Unless, of course, the full framework does work for you. If so, that’s great too!)
When selecting Scaled Agile tools and templates to try out, think pragmatically about how they fit into the context of your business, industry, company culture, and organizational structure. Give teams the agency and empowerment to combine different tools in ways that aren’t necessarily what the framework prescribes, as long as they provide the flexibility you need as an organization to move forward.
Once you’ve landed on an effective process, don’t become rigid. If something isn’t working, pivot or create your own internal frameworks. Then test and experiment until you find a solution. That’s the beauty of Agile — it’s meant to be adaptive and iterative. Embracing ways of working that prioritize freedom, flexibility, and feedback loops ultimately leads to effective and happy teams, incremental product innovation and satisfied customers.
The future of Scaled Agile goes beyond frameworks
This mix-and-match approach is growing in popularity. Digital.ai’s latest State of Agile Report, for example, found that 34% of survey respondents “create their own enterprise Agile framework” or “don’t follow a mandated Agile framework at the enterprise level.”
And PMI, developers of the Disciplined Agile (DA) framework, mapped an exhaustive list of Agile approaches in their “Ways of Working Spectrum” to help users select tools from different frameworks based on the problem they’re solving and the context they’re using it in.
Exciting new ideas and methodologies are also branching off from traditional Scaled Agile approaches. unFIX, created by Jürgen Appelo, isn’t considered a framework, but rather a pattern library, in which “nothing is essential and everything is optional,” whereas FaST (Fluid Scaling Technology) focuses on forming teams around the work rather than making the work fit the team.
Scaled Agile is at a crossroads
The question is: Will we become more entrenched in our existing frameworks, or break away into brand new ways of working?
I don’t think this debate has a binary, black-and-white answer. The evolution of Scaled Agile isn’t about new frameworks replacing old. Instead, I think of it as the roots of Scaled Agile growing new green shoots, offering a swath of complementary tools that Agile professionals can pick from based on their team’s self-organizational needs.
I believe the future of Scaled Agile isn’t about being beholden to a singular framework, unless that framework already works for you. After all, and not to be clichéd, one of the values of the Agile Manifesto is “Individuals and interactions over processes and tools.” You can respect the principles of Agile while offering room for experimentation and flexibility, which ultimately helps teams deliver value to customers faster. And that’s what Agile is all about.
