How to Convince Management to Use Scrum
When I first started my career, I had no idea what Scrum was. On my first day on the job, my manager told me they were “kind of doing Agile.” There was a Scrum Master whose formal job title was “Project Manager,” and he had a certificate hung over his desk that said “Certified Scrum Master.” Aside from holding daily stand-ups, I never really understood what he was doing.
As I progressed through my career, I’ve gone through various organizations. Some of them claimed to do Scrum, but it was very clear that it was not Scrum. Some of them admitted they had no sense of organization whatsoever.
Whenever I tried to bring up the topic of implementing Scrum, I would always receive some pushback. Even after I was formally labelled as the Scrum Master, it’s been a challenge. I’ve spoken with many fellow Scrum Masters who’ve experienced the same exact issue. Early on, I always internalized it as management be stubborn or lacking sympathy. It was only until much later that I realized that I was the one who wasn’t looking at things from their perspective.
These are some lessons that I’ve learned over the years about opening a dialogue with management.
DON’T begin by talking about how the developers benefit
One of the most common things I hear about when it comes to Scrum is that when it’s properly implemented, it helps protect the developers. The traditional role of the “Project Manager” has now been split into the “Product Owner” and “Scrum Master,” which helps prevent despotic behavior. Scrum gives developers psychological safety.
It’s not that the above statements aren’t true.
Yes, they’re arguable points. However, getting management to believe you, is not the issue here. Most people would probably take you at your word.
It’s not that the managers don’t care.
Sometimes people have this notion that managers don’t care about their employees. They only want to squeeze out every last drop of productivity. While I’m certain that most of us have come across such managers, it would be a mistake to make such an assumption of all managers.
It’s that you’re communicating something between the lines that they don’t want to hear.
Whenever you try to sell something to someone, there’s usually one question in the back of their mind: “What’s the catch?”
In this case, if you begin with “protecting developers,” they’ll immediately answer that question for themselves. Protecting developers sounds like it will come at the cost of productivity. While many managers want their employees to be happy, anything that reduces productivity would be an immediate red flag. Even if you spend every effort to convince them otherwise, you’ll be fighting an uphill battle from here on out. It’s best to begin with another argument.
DO begin by talking about working software
Within the Agile Manifesto, there is one particular talking point that I personally find the easiest to sell to management:
Working software over comprehensive documentation
If you’re building software, it’s pretty obvious how important it is to have working software. Scrum has a built-in mechanism to let management see the progress of working software: the demos during Sprint Review. No amount of story points or burn-down charts could ever replace that.
DON’T go into detail about the metrics
Yes, you can produce very beautiful metrics using Scrum.
Telling management about estimates and burn-down charts will likely get you recognition. If you are convincing management to move to Scrum, these arguments would likely help you win.
But if that was what it took to push management over the edge, you also lost.
The moment you start talking about metrics, that is what management will start to think about. They will start to use those metrics to measure progress. When a measure becomes a target, it ceases to be a good measure. Most importantly, they will miss the point of Scrum, and the importance of working software.
When a measure becomes a target, it ceases to be a good measure.
Don’t get me wrong. I’m not saying to not use these metrics. I personally find them very valuable. However, the moment you inform management of these metrics, you’re leaving a window of opportunity for misuse.
DO explain the benefits of flexibility
Moving back to the Agile Manifesto, there is another talking point that I consider to be the poster child of Scrum:
Responding to change over following a plan
In traditional project management, there are times when change is required. However, when it’s calculated, it’s considered a risk, and a cost.
In Scrum, change is automatically built-in. I would even argue that it’s encouraged, as Product Owners are supposed to constantly update the backlog. Of course, we should avoid making changes to a current sprint, but 1–4 weeks of locked requirements is a much shorter length of time compared to the months and quarters of a Waterfall method.
On the other end of the spectrum, in a more chaotic environment that doesn’t have any sort of framework, you will probably see a lot of unorganized and leftover work. Disgruntled developers will be constantly complaining about scope creep, and code quality will very likely suffer. If this is the environment you are working with, it’s probably best if you stick with the “working software” argument mentioned earlier. In chaotic environments, you should have no problems with change, but a lot of problems trying to find working software.
DON’T talk about Scrum like it’s a silver bullet
One thing that bothers me when people talk about Scrum is that they talk about it like it’s a religion. A lot of people make a very clear distinction on what is, or is not Scrum. We even have the term “Scrum but” to mark anything that deviates from Scrum, such as “Scrum but no Daily Scrum meetings.”
I understand the need to make clear definitions. I’m not bothered by that. In fact, if you plan to get certified, you very likely will be tested on these topics.
What bothers me the most is what’s being communicated in between the lines. It’s the subtle implication that “it’s not Scrum, and therefore it’s wrong.” This leads to the corollary “we should be doing pure Scrum because it’s the right thing to do.”
You have to make a case for Scrum. Saying that it’s some sort of magic formula that solves every problem in the world is lazy reasoning. Customer support is an example where Kanban would be much better suited to address customers’ needs on time. Scrum locks requirements in sprints of 1–4 weeks. If you wait 1–4 weeks to respond to customers, you won’t have customers for very long.
There will be times when Scrum is not the answer, and that is okay. But for the times when Scrum is the answer, you should be prepared to explain why. The best way to do that would be to start with the problems that management has.
DO open a dialogue to discover underlying problems
When you ask management for any sort of change, you’re asking them to take on risk. They have to be sure that the risk is worth it.
The best way to understand why management needs Scrum is to figure out what’s bothering them in the first place. Here are a couple of the most common concerns:
I’m worried that my employees are not utilizing their time wisely.
I used to automatically antagonize managers who say things like this. It sounds like the speaker is completely lacking empathy. Sometimes it’s true that despotic managers say things like this. However, this can also be an honest question about optimizing productivity.
If developers are hired to build software, it’s hard to imagine anything more productive than building software. It’s also hard to imagine anything that is a better proof of work completed than seeing the working software. This is precisely why Scrum has sprint reviews.
I don’t know if we can deliver on time.
This one’s a little trickier.
When someone talks about “delivering on time,” it tends to mean that a promise was made to a customer. If this promise was made by management, I would first ask if management made this decision without consulting the developers first. I would then assess if the developers feel pressured to accept such a request without question. If either of those answers is “yes,” I believe there’s a major problem.
When something like this happens, it’s no longer about Scrum, Waterfall, or whatever sort of framework you choose. It’s the fact that management has made a promise on a complete unknown. Yes, things always come up that could disrupt the development lifecycle. On the other hand, making a promise when you simply “don’t know” will have developers pay the consequences.
Delivering “on time” is something that kind of smells like Waterfall, since Scrum environments tend to favor CI/CD. However, there are very beautiful ways to do estimation so that you’ll be able to estimate release cycles. I might cover that in a future article. However, that’s not the main point here. After all, estimation is not technically part of Scrum, at least not anymore. As I mentioned earlier, focus on having working software. Working software is the main proof of progress.
Some people may argue that factoring in release cycles would make this “Water Scrum Fall” or a hybrid approach. It doesn’t really matter to me. Scrum is designed so that you can always add to it. There’s no problem with adding estimates, release cycles, etc. It’s only when you take away something from the framework that it no longer can be called Scrum.
We have way too many bugs. There’s no way we can ship like this.
Bugs fall in the realm of “technical debt,” which basically means anything that happens when developers choose an easy solution to expedite the development process. Technical debt accumulates over time, much like monetary debt.
I’ve seen teams that just create a “bug bucket” and hammer through the bugs like they’re all trivial issues. The problem with this approach is that developers are incentivized to only go after low-hanging fruit.
Again, it helps to think about how we can leverage what’s already built into Scrum to help resolve these issues. Product Owners are supposed to be constantly updating the backlog. If you add technical debt to the backlog in the same manner as the stories, you allow them to make an active decision. Of course, the developers need to help the Product Owners understand the value of technical debt. Good communication is the backbone of Scrum.
Conclusion
Scrum is a framework that really focuses on prioritizing interactions between people. It’s only natural that we take these same skills and use them to speak with management as well. Even if you forget all of this, the most important thing to do is to actively listen to management, and understand where they are coming from.
How have you convinced management to use Scrum?
