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.
I was first introduced to Scrum in 2010 while working at a small company that did services-based IT work for the US federal government. One of the many reasons why I liked it so much was that it presented the possibility for teams to adapt and improve around institutional impediments. In many cases, we could find ways to deliver value in spite of the anti-patterns imposed by the organization. And I saw that promise come true over and over. First as a Product Owner, then a Scrum Master, and later as an Agile coach working across many customer contexts and companies that ranged from tens to tens-of-thousands of employees.
But there’s a very real ceiling to the performance increases an Agile team can achieve. That ceiling is set by the cultural and structural conditions of institutions. If the institution won’t evolve away from foundational problems affecting teams, they eventually become throttled, and performance will drop.
For example, a premise of Scrum is that we’re going to establish a dedicated, cross-functional team that persists long enough to get really good at working together. But what if your company is locked into a culture of skillset utilization and insists that certain people must be shared across multiple teams? Or what if the only way that organization can assemble a team is based on waterfall-like patterns of planning in which all the work must somehow be defined upfront? Or we’re locked in traditional iron-triangle assumptions of fixed-scope/fixed-schedule/fixed-cost, all the while knowing that the initial guess as to what we’re going to build is likely to be obsolete by the time we’re finished?
Generally, the result of all of those scenarios is that the team(s) in question will hit a wall of how much positive change they can effect on their own. Then, their management will blame them for not improving beyond that limit. And after that happens on a few different teams, leadership may start to feel like maybe it’s not the teams’ fault. Maybe it’s actually ‘Agile’ that’s the problem. Never mind all of the productivity, value, and job satisfaction gains we realized from using Agile methods in the first place…
A great example of this is shown in the way some of the early large-scale adopters of Scrum (notably Capital One and Geico) recently decided to offload everyone in their organizations with the word “Agile” or “Scrum” in their job titles. Did those places ever actually realize Agility? Talking to a lot of their recently laid off alumni, I think the answer is maybe at the team level, but no at the institutional level. A recent student who was a part of those lay-offs told me:
“My team was really committed to experimenting to find improvements. We fixed every problem and impediment that we had control over. But every time something came up that required support from above us, the answer was, ‘that’s just the way we do things here.’ And then in the same breath they’d ask me, ‘Now why aren’t you getting any faster?’ When they let us go, they said they’d ‘evolved beyond Agility,’ but it felt more like they’d just given up on doing any of the real change work.”
There’s a saying in the Scrum community that “Scrum doesn’t solve your problems. It shows them to you.” That means that the inspect-and-adapt cadences in Scrum are great for identifying problems in product direction, team behavior, and planning. But the people involved are responsible for taking action to resolve those issues. They don’t automatically get better just because we identified them.
But there’s a dark side to that saying that I don’t think gets acknowledged enough: if we can’t fix the issues we find, having to look at them more often feels worse than if we just ignored them. At a personal level that might mean taking the batteries out of your scale because you don’t like seeing the number it gives you. At a corporate level, that apparently means firing all of your Scrum Masters because they keep pointing out the choices that hurt your teams, products, and customers.
So, that’s my case against suspect #1. Maybe your boss (or their boss) killed Agile because they didn’t like the way it tends to point out uncomfortable truths. Or maybe they didn’t like the way it advocated for treating people like humans instead of machine parts. Or maybe they think they can keep the gains of Scrum without also maintaining the roles and assumptions that made Scrum work. It could be all of the above, I guess.
In our next blog, we’ll look at Suspect #2: SAFe.
While we’ve still got two more suspects to get through, 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 of the skills of an Agilist, but 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.