Does It Make Sense for Developers to Wear the Scrum Master’s Hat?

Who is the Scrum Master? 

Do you need a dedicated person for this role? 

The answer to these questions significantly depends on your scenario. 

Until 2020, there were three scrum roles: Scrum Master, developer, and Product Owner. After the last update in November 2020, the roles shifted into accountabilities, meaning that one person could be a developer and a Scrum Master at the same time. But you have to be careful before making such a decision. First, you must carefully evaluate your situation.

The more self-managing your team is, the less coaching they need. 

The more Agile your organization is, the less coaching your business stakeholders need. 

The more experienced with Scrum the team becomes, sharing accountabilities in the team improves. 

WARNING! When accountabilities are shared at the wrong moment, the effects can be opposite to what you expect, and the team may suffer and eventually collapse.

A typical scenario is for a developer either to become a dedicated Scrum Master or to accumulate the Scrum Master accountability. Does that make sense? That’s what I will elaborate on and share my perspective with you.

How Would a Developer Become a Scrum Master?

Before we talk about the pros and cons of developers becoming Scrum Masters, we ought to understand how developers end up wearing this hat. I’ve observed only two scenarios, by chance or choice. Understanding the difference between them is essential because motivation may differ significantly, and it will play a lot into the odds of success.

By Chance

Imagine you’ve been working as a developer for months, and then the Scrum Master leaves the team. Until a replacement is available, someone will need to wear this hat, or else thriving Scrum will become more and more challenging. On top of that, company managers tend to underrate the value of a Scrum Master. They would potentially encourage the team to work without a dedicated person for this role and measure the results of it, and if nothing explodes, forget about a dedicated Scrum Master.

A developer may take a stand in such situations and say, “I will assume the Scrum Master responsibility.” This can happen naturally, but the motivation for this would be to cover a gap and avoid losing the team’s efforts to get where they are. The challenge with this decision is that management will push for the same amount of output, but since the new Scrum Master is also a developer, trade-offs will have to be made, and focusing on development will probably be a natural preference.

“Doing half of something is, essentially, doing nothing.” ― Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time

By Choice

After years of working with software development, some developers want to go in a different direction. A common choice is to become a Scrum Master or Agile Coach. Given the expertise with software development, hands-on Scrum, and knowledge on how to build products, developers can be successful Scrum Masters when they learn to avoid the traps ahead of them.

Becoming a Scrum Master by choice increases the chances of success because the developer decided to take on different responsibilities. This decision tends to work better when developers opt to dedicate their time to Scrum Mastery and master the art of servant leadership.

Common Traps

Regardless of how a developer becomes a Scrum Master, inevitable traps await at every turn. You must learn how to avoid them; otherwise, failure as a Scrum Master will be your fate. These are common traps I continuously come across:

• Commitment on behalf of the team: “Technical” Scrum Masters know how to create features and can give high-level estimates. Although that could be an advantage, it can quickly backfire. Business people push for commitment, and the Scrum Master may think it’s OK to make promises. This attitude will increase prestige with business people and create mistrust with developers and Product Owners.
• Slide into a team lead: Depending on the Scrum Master’s expertise, this person can slide either into the role of a team lead or a project manager. For example, during Sprint Plannings, they may try to assign tasks to team members because they know who is the best fit for each job. Meanwhile, they forget Scrum Mastery is about servant leadership instead of management.
• Limit team development: Experienced developers have invaluable product development knowledge, which can be used well by Scrum Master. But there’s a thin line between love and hate: Scrum Masters should help team members find answers to their problems, not provide directions or demands on how to solve them. It’s the difference between teaching how to fish and giving the fish directly.

Advantages

Developers shifting into Scrum Masters have several advantages, and they can help Scrum Teams grow quickly. Let me share the most relevant benefits I’ve found:

• Experience with common pains: Nothing teaches more than real hands-on experience. When Scrum Masters have hands-on experience, they can meet the team a step ahead and ask questions that will help team members unlock their potential and grow.
• Understand the importance of focus: Experienced developers know what lack of focus leads to. Therefore, they have compelling explanations on hand to hold demanding business people from flooding the team with requests.
• Solid arguments for holding Product Owners: Scrum Masters and Product Owners function better when each side can help the other evolve. Within previous dev experience, Scrum Masters can help Product Owners find a sustainable balance with Scrum Teams.

Tips to Start this Journey

You can excel in this role if you’re a developer and want to become a Scrum Master. The key aspects are to be aware of pitfalls ahead of you, learn how to avoid them, and use your strengths.

Before you jump into this role, I’d suggest investing significant time into understanding the following:

• It’s a different role: A Scrum Master is entirely different from a developer. Behaviors that would work as a developer won’t work as a Scrum Master. You will need to unlearn some common behaviors and develop new ones. It’s vital to step back from a developer mindset before stepping into a Scrum Master role.
• Learn how to listen more than you speak: Scrum Masters say only what is relevant to the team. A good rule of thumb is to listen 80% of the time and talk only 20%. Make sure you understand the situation before jumping into suggestions or solutions.
• Learn how to ask questions instead of providing answers: Great Scrum Master will hardly ever give answers, but will almost always ask powerful questions.
• Servant leader, not a manager: A Scrum Master is not a team manager; you are on the same hierarchy as all the other members. To excel, you need to be a servant leader, not a manager.
• Name conflicts and help the team solve them: An outstanding Scrum Master has the skills to sense conflicts and name them without influencing the solution. The team is responsible for solving their conflicts, and the Scrum Master should be mindful to identify conflicts and bring them to the team’s awareness.

Final Thoughts

I’ve seen both sides of the coin when it comes to developers becoming Scrum Masters. When they truly embrace the principles of servant leadership, they often stand out as Scrum Masters. Meanwhile, when they fail to step out from a developer mindset, they frequently step on the developers’ toes, which inevitably leads to a horrible outcome with the Scrum Team.

In high-performing teams, I believe experienced developers can combine the Scrum Master role and benefit the team. However, if the team is still adjusting into Agility, a dedicated Scrum Master will be a better choice in the medium and long term.

“Greatness can’t be imposed; it has to come from within. But it does live within all of us.” ― Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time