The Scrum Master and Too Many Hats

With the summer nearly over and fall fast approaching, the Fall season will be upon us soon. Fall is one of my favorite seasons. Professional American Football kicks off (pun intended), the temperature starts to cool off, leaves begin to change, and scary Halloween movies are on the rise. Scary movies are one of my all-time favorite forms of media. With that being the case, I thought I would tell you a frightening story.

This is a cautionary tale not for the faint of heart. Please do not say I did not warn you. If you scare easily, turn back now.

(This is not truly a scary story, but it occurs more often than you think.)

Enter the Scrum Master

A Scrum Master named Jimb sets off on his journey to be the best Scrum Master he can be. With his laptop under one arm and a copy of the Scrum guide clutched in his other hand, he enters… the office building. It feels like any typical day at the office. Team members are smiling. The smell of coffee passes under Jimb’s nose, saying, “you know you want some coffee.”

With a full mug in his hand, Jimb sits at his desk, ready to start the day. The engineering team sits in a co-located space where everyone can easily talk with one another as needed. They have a physical Scrum Board in their shared space that everyone can see. Their working agreement hangs on a wall nearby.

Jimb has been working diligently to get to this point. He has set up a time to review the Scrum Guide’s different aspects with his team. He ensures the team delivers high-value work while meeting their definition of done. Jimb has stepped in where needed to remove blockers and impediments from the team. Jimb is reliable. He is helpful. He is one step away from going too far.

Where things start to go wrong

The First Hat

It just so happens that today is no ordinary day. The Product Owner of the team is on a weeklong vacation starting today. The manager for the engineering team has asked Jimb to step in for the week the Product Owner is out. Feeling it will only be a week, Jimb agrees and goes about his week with an additional hat of responsibility.

One week later, the Product Owner is back and ready to go. Jimb attempts to relinquish the product owner hat, but strangely enough, the team and others continue to ask him to perform occasional product owner duties. He thinks nothing of it.

The Second Hat

It would turn out that a deadline approaches fast, and the team is stretched too thin to meet the deadline. They cannot hope to develop and test the next release in time. The ever helpful Scrum Master volunteers to help out to relieve stress for the team nearing the deadline. Sure enough, they reached the deadline and delivered on time.

Thinking he is done with his test engineer hat, Jimb focuses on his Scrum Master duties. Often, a team member or the Product Owner asks for his help with a testing effort. It does not bother Jimb, but he is starting to feel like less and less of a Scrum Master each day.

Piling on the Hats

In the days that followed, this pattern continued. Jimb still made sure different Scrum Events occurred, but the rest of his time was filled with his alternative hats. The outcome of these changes was that the effects of having a Scrum Master diminished slowly. Unfortunately for the team, these changes went unnoticed. They were under the impression that things were going well because they were still doing the different Scrum events established in their early days. Little did they know they had started getting away from their definition of done. Their backlog began to grow at an unmanageable rate. And they had stopped making frequent improvements to how they were doing things. In the end, they were leveraging Scrum in name only and lost nearly all the value it had given them in the beginning.

This may not sound like a true horror story, but it happens from time to time. This may have even happened to one of your teams.

How can you avoid this story happening to you?

Looking back at the story of Jimb, we can observe a few things.

For starters

At no point does Jimb get to truly remove the additional “hats” he has taken on

It is okay to step in to help remove an impediment or blocker, but once it is removed, the Scrum Master needs to be able to move on. A team is meant to be self-organizing and able to do the work independently. Adding a Scrum Master to that takes away from the team being self-sufficient.

Next

Was the deadline truly immovable? 

The knee-jerk reaction of putting more bodies on a problem is one that nearly all engineering teams have faced. In this case, the Scrum Master was added as the fill-in. The Agile Manifesto states, “Responding to change over following a plan,” as one of its defining characteristics. In this case, You may question if the response to change was having the Scrum Master help out. But others may argue that this was a team sticking to a planned date.

A way to respond here is to weigh your options. Consider the project management principle of the Cost-Time-Quality Triangle here. Does moving the Scrum Master help with this scenario, or would moving the time be a better option?

Rip off the bandaid

Jimb is merely a bandaid for a more significant team issue, and bandaids fall off over time.

The first issue the team faces, in this case, is when one of them goes on vacation, they worry that they will implode. Had the team prepared the backlog and kept it in a state where someone could go missing for a week, they may have avoided the need for Jimb to fill in. Moving Jimb to the Product Owner role only hides the backlog issue. Considering the role of Scrum Master, Jimb could have taken the time after filling in to help the team build a better backlog. Unfortunately, the team gave Jimb a different hat and had him move on.

As part of a Scrum Master’s role, as defined by the Scrum Guide, they should be helping the Product Owner “find techniques for effective Product Goal definition and Product Backlog management.” This should take priority over taking on additional responsibilities as it is one of the initial responsibilities a Scrum Master has.

In the end

Jimb lost sight of what he was supposed to be doing over time. The coverage of the hats blocked his vision. Balancing a couple of hats is manageable. Balancing too many can cause someone to fall over.

The hats may vary from case to case. In the end, the tale of Jimb is all too common. When allowed to work with a team in a way the Scrum Guide has defined, a Scrum Master can help a team in numerous ways. It is a slippery slope to end up with too many hats. The sooner a team corrects this, the easier it is to get back on the right path. Hopefully, if you see yourself going down this road, you will heed my warning and not let this story be yours.