The number one reason Scrum implementations fail, and how to succeed
In my experience as an agile coach I’ve seen the promise of scrum realized as teams exchange a waterfall, top-down culture for ownership, clarity, and a product-over-politics mindset. I’ve also, unfortunately, found bastardized, routinized forms of Scrum that devolved into yet another way for management to browbeat and micromanage.
What separates the two?
Imagine this conversation between a business manager and a team fresh off a Scrum training:
Manager: Alright, now that the new Scrum process is in place, who tells marketing when we’ll deliver the new email featureset?
Newly Appointed Scrum Master: Actually we’re not sure, and the 2020 Scrum Guide has eliminated all language about estimation so it may not even be a valid question.
Manager: Okay look, I understand going by the book, but seriously, how long will the featureset take? Can someone give me a date?
Increasingly Trepidatious Newly Appointed Scrum Master: Well, we don’t yet have our story point estimation baselines, so even if we did do estimations we’d need a couple months to nail down our velocity. In the meantime, how about we loop you in to regular demos?
The Manager scratches his head, glares at the agile coach across the room, curses the $25k he spent–probably $50k in lost productivity–and says he’s got to tell marketing something.
The Scrum Master caves and blurts out a number she thinks is halfway between pissing off her boss and pissing off her team.
At this point, congratulations…
A Scrumbomination is born! From here on out, Scrum events and artifacts will become little more than cruft, bolted onto the same creaking old approach that was underperforming.
How did the Scrum implementation go wrong?
Failure to update management’s mental models
Before Scrum, the manager’s mental model for developing software was akin to building a house, with stable requirements, architectural sign-off before work begins, and the ability to accurately forecast timelines. The problem is that after Scrum, that model remained unchanged.
A manager with an updated mental model wouldn’t ask “when will it will be done?” but rather “with the information you have now, what delivery date can I plan against with 50% confidence?”
In this version of the question, the manager acknowledges the profound uncertainty of development and gives the team permission to be wrong, while still getting a date from the team. By asking this way, they provide proof they’ve changed their mental model from “timelines are commitments” to “timelines are estimates.”
In my experience, when a manager groks the deep truth Scrum is built on, that development is a wily and unpredictable ride, the team feels seen and loyalty and motivation naturally follow.
Here are a couple more mental models that often need tweaking for a Scrum team to thrive.
Velocity is not value
Almost by definition, the job of a manager is to ensure those they lead are delivering value. How can they do that? It’s all too easy for managers to reach for the esoterica of story points and sophisticated looking burndown charts. And indeed, these can be useful — it helps to know if things are slowing down or speeding up.
The trap, however, is to imagine making stuff is the same as making valuable stuff. Ultimately, managers are judged not on the velocity of their teams, but the value they deliver.
A manager who understands this doesn’t dwell on last sprint’s story point totals, but rather a holistic understanding of the value the team creates. Appropriate metrics include net promoter score, monthly active users, defect rates, customer churn, and so on.
A Scrum team with a manager focused on outcomes like these can divert energy spent on hand wringing about last sprint’s velocity into energy spent actually delivering value to stakeholders.
Products aren’t projects
Have you ever tried to explain to a digitally uninitiated manager why even “finished” software requires maintenance? Unless you can change their mental model from a project to a product, you might as well be selling beachfront property in Arizona.
Projects are finite: they have a start and a finish. Managers like projects because they can be allocated in a budget and then forgotten once completed. Products, on the other hand, do not finish: they require continuous investment because the technical and user landscapes are always shifting.
A manager with a product mindset asks what resources the team needs in order to maximize value production, not how little time and money can be provided in order to achieve an end.
When Scrum teams hear managers talk like this, they receive the message that they are supported rather than squeezed. I’ve found no better resource for training managers on this topic than Mik Kersten’s excellent book Project to Product which fleshes out the project to product shift in detail.
Succeeding with Scrum
Scrum is built around deep truths about software development, and when those truths aren’t acknowledged by the entire organization, it manifests as conflict. Dan Rawsthorne goes so far as to say Scrum isn’t a process so much as an organizational debugging tool. In my experience, he’s right.
So what’s the number one reason Scrum implementations fail? The inability to manage up. To succeed, update these three mental models:
Timelines are estimates, not commitments
Velocity isn’t value
Products aren’t projects
Happy Scrumming.
