The Incredible Disappearing Scrum Master
Pull back, then let go!
Reading time: 6 minutes
I just quit my job! 🎉
But despite that lining up really well with the title of this article, it’s not what the title is about. It’s actually about the idea that the best Scrum Master is the one who goes away over time.
And the related idea that the best Scrum is the Scrum that stops being Scrum over time, too.
At my last employer, I was officially a JavaScript Developer, but bit by bit, I proved my value as a Scrum Master to my manager and with his support, I was able to spend more and more of my time focusing on that role. I took my teams through countless iterations of experimenting, learning, and improving.
By using Scrum, I learned how Scrum is actually meant to help us.
This is how I believe Scrum intends to help us improve the way we work on something with high complexity. I think of it as “the nature of Scrum:”
Add structure and overhead
Slow down
Gain understanding and reduce complexity
Refine the structure
Repeat steps 3-4 as needed
Gain fluency
Remove the overhead
Speed up
It’s kind of like that toy car that you have to pull backward to wind its spring before you let it go and it flies away. Winding a spring is a simple example of adding potential energy.
A Real Life Example
Our first major hurdle to improve as a floundering Scrum Team was to understand how to estimate when our work could be done. We started in the beginning with a murky mandate to estimate using Story Points, but no understanding of how that was intended to work. I took it upon myself to research the proper use of Story Points for estimation and the reasons we would want to do it and teach the team.
It didn’t go that well.
Most people wanted to scrap Story Points altogether and just estimate in hours. I tried to explain why that might be problematic, but I was not convincing enough, and we eventually settled on doing both - estimate complexity in Story Points, and time in hours. We created a bulky process for getting a clear picture of the team’s capacity in hours at the beginning of each Sprint Planning.
After four Sprints, the team was tired of the overhead of having to estimate both ways.
By then it was clear that our time estimates were wildly inaccurate, even when we strictly tied work items to the people who estimated them. Because the Story Point Estimates were purely relative, they were much more accurate (at least in determining which Stories would be harder to do than others).
We dropped the time estimates, and the team focused on improving our use of Story Points. We relaxed our Capacity planning to just account for days off or committed to other work.
We set a descriptive guideline that helped people understand why we would vote for three or five on any particular story. On our team, a zero corresponded with “This Story is so simple, my grandmother could do it, and she’s dead.”
I might have stricken the last part of that line.
Over time, we adopted more and more improvements to the way we considered work, like INVEST criteria for our User Stories and focusing on the 3 C’s. We phased out the use of the guidelines, since the team understood more and more how relative estimation went.
Our stories got clearer and easier to work with. Our Product Owner brought them to us in better condition, with a clearer idea of the intent behind each User Story. We phased out focus on the 3 C’s and mostly brushed past the INVEST criteria.
Our most important question after discussing each Story or task in Sprint Planning was “Does anyone feel less than 100% confident we can deliver all of these things by the end of the Sprint?”
After a little longer, developers stopped asking “how many points do we usually complete?”
Then, one day… we just stopped estimating the User Stories. We didn’t need to anymore. It just didn’t serve our needs. My facilitation in Sprint Planning was now basically down to asking “Anybody feel unsure we can get all this done?”
A Note
Story Points, User Stories, Estimation… these things are not part of Scrum. They’re tools we decided to use. But it’s because we used them within Scrum that we were able to systematically move through many different ways to use them and understand them, until we didn’t need them at all.
Scrum does not solve the problems itself. It merely gives us the guardrails and structure that allow us to think about how to solve problems without getting bogged down or lost.
Extrapolation #1
There is a lot of talk that the ultimate job of a Scrum Master on their team is to render themselves obsolete.
I like this idea - it’s less about the problems you solve and more about instilling the ability to solve these problems and use Agility in your teammates themselves, so eventually you’re not needed.
In this case, you think of the Scrum Master on your team as the overhead. It’s important to have you at the beginning so that you can improve the way your team works while transferring the knowledge and skills to the rest of the team members. Then eventually you remove the overhead.
Extrapolation #2
There is much hubbub made by some about the “immutability” of Scrum. Scrum is immutable, so that means you can’t change it at all, they say.
I disagree with this interpretation. The way I see it, Scrum is just a framework that helps teams achieve Agility. Scrum is immutable, so that means you can’t change it and still call it Scrum. But who cares what we call it?
If you use Scrum, but change something, then it’s still a framework, and as long as you’re changing it intelligently, it should still help your team to achieve Agility. Remember the nature of Scrum:
Add structure and overhead
Slow down
Gain understanding and reduce complexity
Refine the structure
Repeat steps 3-4 as needed
Gain fluency
Remove the overhead
Speed up
The nature of Scrum is to add the overhead (Scrum itself), then constantly revise it to make it less complex and burdensome, until it becomes our own nature. Then we remove the overhead. We remove Scrum, piece by piece, as we gain Agility.
Subscribe to my newsletter to get it sent directly to your email inbox every week, and connect with me on LinkedIn at https://linkedin.com/in/scrumify.
Whenever you're ready, here's how I can help:
If you’re trying to Get Your First Scrum Master Job, check out my video course that walks you through the 15 things you’re going to need to do.
I've created a framework for Personal Agility called Scrumify. Click this link to read it for free.
I host cohort programs for aspiring Scrum Masters looking for their first experience on a Scrum Team. Click here to sign up for the next one.
Join the Scrumify Community! I just launched a Discord channel for Agilists and aspiring Agilists to chat in real time, make connections, and help each other - and it’s free! Click here.