The Era of Copy-Paste Agile Is Over
The Ctrl + C and Ctrl + V of Agile Frameworks Will No Longer Cut It
The Agile job market seems to be in turmoil: Many Scrum Masters and Agile Coaches are struggling to find a new job. What happened, and what new reality must we all adjust to?
I believe we’re seeing this seismic shift in the job market because we’re experiencing the end of the Copy-Paste Agile era. Simply possessing some fancy certifications and being able to copy-paste Agile frameworks is no longer good enough.
The Agile Industrial Complex has milked organizations dry. Businesses are exhausted from being buttered up with Agile buzzwords without any lasting results. This is why organizations have frozen many Agile positions despite many qualified candidates available to snatch up.
How did we end up in this big mess?
Let’s start by answering that question by talking about Eskimos. I promise to tie it all back to the new Agile future I expect we all must adapt to in the upcoming years.
What Can We Learn From Eskimos?
Eskimos* have a much richer vocabulary for describing snow than we do. In the Iñupiaq language, there are at least 70 terms for describing ice, such as utuqaq, ice which lasts year after year, and auniq, ice with many holes.
*After publishing a few readers made me aware that Eskimo may he considered a derogatory term in some parts of the world and can refer to either the Inuit and Yupik. I apologize for any offense and from now on I will refer to the Inuit. I kept the mistakes in the beginning to help raise awareness, and because we all make mistakes.
Why do they have so many different words for frozen water? Well, because their survival depends upon it. Snow and ice are an everyday affair for the Inuit. Being able to describe the daily reality you’re facing accurately goes a long way.
Let’s contrast this with the Netherlands, where I’m from. We don’t possess such a rich vocabulary to describe snow and ice. The famous Dutch Elfstedentocht, meaning eleven city tour, where we ice-skate around 200 km (~ 124 miles) through eleven cities over ice, hasn’t occurred in over 27 years because it wasn’t cold enough for the canals and rivers to freeze.
As you can imagine, it’s unlikely that a rich tapestry of terms to describe snow and ice would evolve in a rarely cold place like the Netherlands. However, looking at the world of water, the Dutch suddenly have a rich vocabulary. Even many English maritime terms like yacht, deck, and starboard all have their roots in the Dutch language.
In the realm of Scrum, you can see something similar happen with the language and labels that have developed over time to describe Scrum implementations.
There are a gazillion labels to describe Scrum that doesn’t work:
The list isn’t even exhaustive. You could easily find another 50 labels that were invented by people to describe Scrum that doesn’t work.
There are even some labels for Scrum that does work, but they have been mostly invented for marketing purposes to position their certifications:
The amount of labels for Scrum that does work are rare. There are far more labels for Scrum that doesn’t work, than for Scrum that does work.
Why is there such a disparity between labels for Scrum that doesn’t work and Scrum that does work?
Sucky Scrum is Extremely Common
Just like snow and ice aren’t that common in the Netherlands, good Scrum is extremely rare. I’ve never arrived at a team and seen great Scrum. Ever.
There are so many labels for Scrum that doesn’t work, because that’s the daily reality we’re all facing. Most of the time we encounter sucky Scrum implementations that don’t really work all that well. Our Scrum vocabulary has evolved to help describe the current reality of mostly sucky Scrum implementations.
The next question then becomes: why is bad Scrum so extremely prevalent?
Well, let’s try to answer that by looking at how Scrum is supposed to work:
Scrum guides the team on how to work with Scrum through rules, values, accountabilities, artifacts, and commitments →
The Scrum team is supposed to figure out their own way of working and terraform the organization so it’s hospitable for team-level Scrum →
The team gets stuck with team-level Scrum that’s far removed from the Scrum Guide, and the organization doesn’t fundamentally change to support self-managing teams. →
The organization changes Scrum, and Scrum doesn’t change the organization.
In short, Scrum gets copy-pasted and tells teams how they should work, and then the conditions necessary for Scrum to work should be magically created by said teams. This doesn’t happen because Scrum Teams often cannot create the conditions necessary for Scrum to work well.
I believe there are two reasons for this inability to terraform organizations with Scrum:
It’s rare for people to know the ins and outs of Scrum. You often see fierce debates about basic things we should have figured out by now. Scrum is often in the foreground while it should be in the background. It’s not all that important, but inexperienced people make it important because it’s what they believe they know.
Having Scrum expertise doesn’t mean you have the skills to create the conditions necessary for Scrum to work. Our knowledge of Scrum stops being the problem quickly and the bottleneck becomes our ability to influence others and the organizational system to change the way of working.
To be fair, point 2 is incredibly hard. I believe point 1 should be easy, but over time I’m no longer convinced that’s true. Scrum misunderstandings are so extremely prevalent and pervasive after more than two decades of being around, that I have no hope for it to change.
So, in short, what’s the real problem? I believe Scrum has a glass ceiling built in by design.
The Glass Ceiling of Scrum
Expecting teams to change organizations to support their way of working isn’t something we commonly see happen because they lack the knowledge and expertise to do so. What’s more likely is that the organization’s system bends Scrum to fit the existing system, and that’s precisely what we see happening.
Hence, we’ve got all the different words for Scrum that doesn’t resemble real Scrum. We see this happening because:
“A bad system will beat a good person every time.” - W. Edwards Deming
To keep with our Inuit theme, Scrum is like an igloo that melts in most organizations. The system actively fights against the invasive Igloo until it melts. After we're left with nothing but a puddle of water we become frustrated and exclaim: let’s do a better job the next time!
And then we go back to building our sophisticated igloos that keep melting. It’s really no wonder we Scrum practitioners have so many different words to describe all of these melting igloos they stumble upon within organizations.
The problem is that we’re foolish enough to believe that an igloo will terraform a hostile environment, no matter how awesome that igloo looks on paper.
How do we fix our sour Scrum-Igloo situation? Well, I believe the answer is pretty simple: we should start the other way around. We shouldn’t start with the igloo, but with the conditions, we’d like to create in organizations.
There’s nothing radical about this. In fact, this is how the Agile movement started. We’re currently wasting our time forcing a purposefully incomplete process on self-organizing teams in organizations that don’t want to work that way.
Bye Bye Copy-Paste Agile And Back to Square One
We’re back to square one: where we were before the Agile Manifesto was written, as expressed beautifully by John Kern:
“After we did our thing [Writing the Agile Manifesto], it felt awesome. Like we unleashed freedom for millions of people… now we’re back to where we were fighting some giant process thing.” - John Kern on a couch with Alistair Cockburn
Through the commercialization of Agile, also known as the Agile Industrial Complex, Agile became the very thing it tried to topple: a giant process monster that inhibits teams from doing the right thing at the right time. Teams all over the world are copy-pasting all these bloated approaches and practices, that don’t survive first contact with the organizational system.
We’re currently in the era of copy-paste Agile, where we’re copy-pasting practices and frameworks, in the foolish hope that they will make a difference. The business has caught on to this folly, and currently Agile Coaches and Scrum Masters are struggling to find new jobs, because the copy-paste mentality isn’t good enough.
Instead of forcing processes and ways of working, we have to go back to Agnostic Agile. We agree not to let any framework specifically dictate how we must work, but we let our situation dictate the best course of action.
We need more agnostic tools, like Dysfunction Mapping or unFIX, that allow you to apply patterns because your situation demands them, not because the framework conveniently prescribes them in ways that fit with our existing ways of working and thinking.
We need less trust in all these Agile dieting fads and more trust in experimenting and figuring out what works for our situation, using proven patterns. Because let’s be real, Scrum is purposefully incomplete. It won’t work unless you add some unique mix to it that makes it work in your situation.
If we assume teams can supplement Scrum as expected by Scrum, then why can’t we simply let them figure out their whole way of working? Why is that a bridge too far and do we get sucked in these soul-crushing Scrum Guide discussions?
It’s time to forget about all these silly guides with prescriptive team-level and process rules and shift our focus and attention to discovering what patterns work best for our situation.
Because that’s what matters most: results, not adherence to any guide or prescribed process, made by fallible humans with their own commercial interests at heart.
Let’s wave goodbye to the foolish Copy-Paste Agile era and revive Agnostic Agile as the Agile Manifesto originally intended
I’ve enjoyed your article, thank you. Unfortunately I’ve also observe all the things written, and the saddest one, in my opinion, it was the importance of the process: “Scrum is often in the foreground while it should be in the background. It’s not all that important, but inexperienced people make it important because it’s what they believe they know.”
I don’t know why some people make it so important. It is important but is not the end goal to “do scrum”
The biggest question here - once you realize the place you are at has these issues, how do you course correct when you're just a little ole product person in a giant monolith corporation? There's a good chance that, if your company is big enough, you probably have 2-5 different delivery models that exist at the same time.