There’s been a trend lately of IT thought-leader types claiming that the Agile movement is dead or dying. There are, of course, a ton of organizations still using Scrum and other Agile methods to great effect. And I still believe that Scrum is responsible for amazing improvements in the quality of life and value delivery […]
There’s been a trend lately of IT thought-leader types claiming that the Agile movement is dead or dying. There are, of course, a ton of organizations still using Scrum and other Agile methods to great effect. And I still believe that Scrum is responsible for amazing improvements in the quality of life and value delivery for teams.
But I can’t deny that public enrollment numbers in certified training have fallen off a cliff, as has demand for experienced Scrum Masters, Agile coaches, and related titles in the job market. So, if the perception that Agile is dying is starting to take hold, the trained criminologist in me wants to know: who killed it?
After thinking long and hard about this, I’ve come up with a few suspects. Each of them will be addressed in a separate post. I’m relying on you, dear reader, to be the jury.
In the first post, I outlined a case against suspect #1: your boss. Now let’s move on to suspect #2: the Scaled Agile Framework for Enterprise, also known as SAFe.
If you ask the global community of seasoned Agile coaches who’s responsible for killing Agility, I’d guess at least 80% of them would start their list with a combination of their favorite expletive and the word, “SAFe.” I saw SAFe begin to really take off around the same time I began seriously pursuing a career as a Certified Scrum Trainer (2013-2014). In the decade since, it’s gone from “a thing I’ve heard a few companies are trying,” to being a prominent keyword in most Agile job postings and a core feature of the professional world’s understanding of “Agile.” This puts the entire Agile ‘brand’ in an odd position where the perception of Agility’s success is tied to the perception of SAFe’s success. For me and many others, that feels like the entire world deciding to define your whole family based on the actions of your weirdest cousin.
Before explaining why SAFe isn’t good for the Agile community, let’s look at where SAFe came from, what it is, and how it undercuts many of the core principles of Agile.
This will be one of my longer articles; so, if you know all of that stuff already you may want to skip ahead to the conclusion.
Once upon a time (the ‘90s), companies wanted to build software. But doing that came with some big problems. One of them was that nobody ever knew how long things were going to take to build. That made budgeting and estimating a potential return on investment really hard.
Another problem was that scope would often creep dramatically as companies sought to deliver products against markets full of moving targets. That would mean that timelines would get extended even further. Ultimately, the only way anything ever got finished was through huge amounts of unpaid overtime and intravenous caffeine.
Nobody liked those problems, so people looked for solutions. And the flavor of solution that most large organizations landed on at that time was called Process. The thinking went something like this:
“The problem with software development is that we’re always having to figure out how to do everything for the first time, and then we have to make up the rules for how to deliver it as we go. If only there was a standardized process for building technology, things would be more knowable, predictive, cost-effective…”
So “Defined Process Control” approaches became the rule of the day. Some orgs went with professionalized project management approaches that were being created by the Project Management Institute (PMI). Others went for self-defined process approaches, using the Capability Maturity Model Integration (CMMI) as a ‘process to define process’. Others turned to an IBM subsidiary called Rational and an approach called the “Rational Unified Process” (RUP). A significant portion of RUP had to do with defining requirements up front, and many of the techniques for doing that were based on the work of a guy named Dean Leffingwell. A lot of companies bought training and consulting services to help them do development with RUP.
But RUP didn’t fix the original problems for the same reasons that no other ‘waterfall’ methods work in most new product development: Rigorous scope definition doesn’t help us when most of the requirements aren’t knowable at the front of the work, and the ones that are known are likely to change before we’re done. Organizations stopped buying RUP, and started looking around for new practices that might help them get something usable out to the market quickly, and Agile frameworks like Scrum started to pick up steam.
Meanwhile, the RUP gurus had to find something else to do. Many of them decided to make a space for themselves in the Agile community. Dean Leffingwell got some folks together to tackle a need they perceived in the Agile scaling space, and SAFe was the result.
A critical part of Agility is the recognition that small teams outperform big ones. We build small, cross-functional groups and then let them bring ideas in an incremental fashion. That gets us rapid feedback and front-loads return on investment.
But what if we need to do something that’s bigger than one small team can deliver in a given length of time? We don’t want to add more people to the small Agile teams and make them less effective. Instead we might try an Agile ‘scaling’ method to become a team of teams. There have been a lot of approaches for Agile scaling over the years. These include the Dynamic Systems Development Method (DSDM), Large Scale Scrum (LeSS), Nexus, Scrum@Scale, and, of course, SAFe.
The general premise of these frameworks is that you will have a combination of individual Scrum teams functioning together as a unit, with the scaling approach guiding how to deal with the mechanics above the single team level.
SAFe’s approach is to build a hierarchy of layers with 5-9 Scrum teams organized together into an Agile Release Train (or ART). Multiple ARTs, in turn, might nest within a “solution train,” and potentially multiple solution trains might roll up within a program portfolio. This framework has evolved significantly over time.
I was first certified as a “SAFe Program Consultant” in 2014, and learned it as the 3-tier 3rd version. Version 4.0 increased the layer count to 4, adding a “value stream” layer between program portfolio tier and ARTs, then version 4.5 made that layer optional. By the 5th version of the framework (and continuing in version 6.0), SAFe shifted to a choose-your-own-adventure structure where an organization would decide which combination of layers best suits their needs.
It’s not surprising that folks with long careers instituting ‘process’ would look at Agile methods and see their inherent lack of process as a problem to be solved by structure. I imagine them thinking something along the lines of:
“Cross-functional teams that constantly deliver value! Wonderful! All that’s missing are many formalized procedures dictating how they should be allowed to do that!”
Unfortunately, all that structure results in an organization that is highly unlikely to ever realize business Agility. Here are a few reasons why that happens with SAFe:
You’ll find common Agile ideas throughout the training and practice descriptions that the SAFe folks put out. But the mechanics of the framework often lead organizations to behave oppositely. An easy example has to do with the question of authority and scope in decision-making. SAFe’s stated position on this mirrors what you’ll find in most single-team approaches to Agility:
Decisions should be localized by default, and globalized only when necessary. Teams are closest to the best information and should be empowered to make whatever choice they need to pursue value. Decisions should be made globally only as a rare event and only when circumstances demand it (such as when there’s a huge economy of scale to be realized by applying one choice to a whole organization).
Great! That reminds me of the 10th supporting principle from the Agile Manifesto: “the best architectures, requirements, and designs emerge from self-organizing teams.” But what happens in practice? Architectural choices are made above teams by cross-cutting System Architect and Enterprise Architect bodies. Requirements are dictated to teams through a cascade of hierarchical backlogs. Design questions are aggregated and decided outside of teams in a separate ‘Lean-UX’ pattern.
Organizations are bad at understanding when they need to use Agile scaling. Scaling frameworks like SAFe are supposed to help us deal with the complexities of being a super-team of cross-functional teams working in unison on the same product. But what if we’ve never had cross-functional teams? What if all of our value streams are in skill-silo teams?
Surprisingly SAFe’s answer to that question is the same as single-team Scrum, Scrum@Scale, Nexus, and LeSS: you should reorganize the siloed teams to be cross functional and simplify value streams to remove inter-team dependencies. Restructure to remove complexity. But that’s not the message that so many organizations take away from SAFe’s training and their many certified consultants.
Instead they look at SAFe mechanisms like “Program Increment Planning Events” as an effective way to visualize (and somehow thereby manage) all of the complexity inherent in their current structure. That false sense of safety removes the imperative to re-engineer that complexity out of their value streams. This tempts leaders to fall into a common trap: confusing awareness for control. Just because we visualized a bunch of risks doesn’t mean that any of them have been mitigated.
Managing complexity instead of reducing it is bad enough. But implementing SAFe can make the problem much worse. Most frameworks market themselves as a paradigm shift: stop doing whatever you were doing before and start doing this better thing instead. You’ll certainly see language like that in SAFe’s materials. But that’s not what happens in practice.
Instead, leaders come back to work from SAFe training and decide to maintain all of their existing complexity and layer SAFe right on top of it.
“We used to have a Product Management team that made all of our decisions about to build for next year, but now we also have a Program Portfolio Management team, Product Managers, and Product Owners.”
Who has the authority to make choices about what product or process in that structure? Usually the answer is, “everybody… except teams.” So much for nimble decision-making!
For all the ‘process’ that SAFe presents, it’s still missing a few related to bottom-up feedback. Other scaling approaches include scaled up versions of retrospectives and product reviews. In LeSS, for example, at the end of each sprint teams conduct their own individual retrospective, followed by a larger retro that includes representatives from each team. That means that if a team is dealing with an impediment they can’t fix on their own, they have a venue every sprint to ask for help from the wider organization. In Nexus, all teams attend a shared sprint review so that everyone has the same understanding of how the product has been advanced by the work of every team involved. There is no such equivalent to these patterns in SAFe.
Above-team planning is done all together on a quarterly basis, but teams only review sprints and conduct retrospectives individually. Product feedback is expected to bubble up from team Product Owners to higher levels of Product Management. But if individual teams aren’t delivering every sprint and communicating with customers, the only feedback their Product Owners can give is limited to either, “yes, we finished everything” or “no, we didn’t.”
SAFe assumes that at the bottom layer of their framework groups within an ART will be organized as Scrum teams. SAFe includes the notion that some teams might use Kanban instead, but it’s assumed that most teams will use Scrum and work in sprints. But the SAFe conception of Scrum differs from that of the global Scrum community in a few ways. Many of these changes may appear small, but can have far-reaching impacts on the health and effectiveness of teams.
For example, most experienced Scrum coaches (including me) would tell you that the role of Scrum Master is most effective when it is a full-time role on one Scrum team. That can be a tough sell in organizations that don’t understand the value a good Scrum Master brings to the team. SAFe’s answer is to take a “pragmatic approach,” and allows for a Scrum Master to be shared across multiple teams, or for the role to be combined with another job on a team. I’ve written about why this is a problem in other articles. In short, it creates a dynamic where a multi-hatted Scrum Master never has the time and attention to increase team effectiveness. That dynamic then becomes a self-reinforcing loop that all but guarantees that an org will never understand the value of Scrum Masters.
Another example of SAFe instituting a small anti-pattern with big implications has to do with team-level estimation of product backlog items. Agile frameworks use relativistic methods of estimating because they’re quicker to perform, support backlog refinement discussions, and maintain enough accuracy to plan realistically. But those fuzzy estimates are famously annoying for people at the enterprise level because they don’t relate directly to linear measures of time. It can also take teams a few sprints to negotiate a shared understanding of what the estimates mean.
The SAFe approach to this is to mandate that teams all use the same estimating scale (story points), and attempts to level-set the possible scores with a well-meaning bit of guidance: Assume each team can complete 8 story points of work per sprint for each full-time team member. That’s just supposed to be an initial understanding, and teams thereafter would plan iteration capacity based on past performance. But that guidance creates so many problematic assumptions:
To be clear, SAFe isn’t telling people the things bulleted above. But I’ve seen organizations start from that little bit of estimation guidance and draw exactly these same conclusions again and again.
To me, SAFe has accidentally poisoned ‘Agile’ as a brand. SAFe has taken on the identity and language of ‘Agility’ without delivering actual Agility. Organizations saw the need to ‘become Agile’ either as a way toward innovation or to stay competitive. Over the last decade, SAFe has positioned itself as the way for large organizations to institute Agility. A big part of its appeal has been that it presents the appearance of Agile adoption without making organizations behave much differently than they were before.
I will certainly fess up to own my contribution to the problem. Early in my journey as an Agile coach, I didn’t really see the harm potential of SAFe. Lots of my public sector customers were interested in SAFe because it made them feel comfortable adopting the ‘messiness’ of Agility. I taught SAFe classes as an SPC when my customers asked for them. I coached SAFe programs because my customers asked me to.
At the time I saw it as a kind of Trojan Horse: if SAFe got real Agilists in the door, maybe we could get them to actually be Agile by changing things from the inside. But that never really happened. Instead, it enabled a bunch of existing anti-patterns and layered on a bunch of new ones.
And now, the success of SAFe’s marketing has become a huge trap for Agility in general. The pattern we’re seeing is this:
If you’re wondering what step #8 is, it’s apparently “fire everyone with the word Agile or Scrum in their job title.” For recent examples, see institutions like Geico and Capital One. In all of that, it wasn’t Agile that failed them. It was SAFe.
If we’re lucky, sometimes companies swap out SAFe for something more tenable. John Deere, apparently, was an early SAFe implementer that tossed the framework in favor of Scrum@Scale. I work with a large U.S. government program that spent a year attempting SAFe before jumping ship to LeSS.
So, the issue is this: a lot of people have come to think that Agile means SAFe. But SAFe doesn’t deliver Agility. Therefore, Agility isn’t possible. The more that idea takes hold, the shorter the remaining lifespan of the Agile movement.
While we’ve still got one more suspect , I’m not ready to accept that Scrum or Agility are actually dead. One reason for that is that I keep seeing job postings from companies trying to hire someone with all the skills of an Agilist, just under different titles. That tells me that while people may be leery of the vocabulary, they still understand the value proposition of the people who made teams great.
So, if you’re looking for those skills, certified Agile training is still a good place to find them. Take a look at all of NextUp Solutions’ trainings here.
4 Reasons Why Agile Scaling Goes Wrong
Agile frameworks are predicated on the notion of forming small, cross-functional teams. A low number...
Agile scaling is always a hot topic for students and organizations dealing with the complexities...