How to be successful in Scrum without a dedicated Scrum Master

Traditionally, a Scrum team has three roles. The developers, the Product Owner, and the Scrum Master. For whatever reason, it seems as though the Scrum Master role is the one most often missing from the teams. Can Scrum and a Scrum team work without a Scrum Master?

The short answer is yes. I believe it is possible. I have actually been Product Owner (PO) multiple times without a Scrum Master (SM) and we have had success. The longer answer is a bit more complicated. The SM role was created for good reason and not having one will lead to some negative effects.

To understand how to have a team without SM we need to first clarify what the role is.

The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 

What does a Scrum Master do?

A SM serves many purposes. Chiefly, the following three seem to be most important:

  • Coaching the team members on agile principles 
  • Ensuring team productivity by removing impediments and resolving internal conflicts
  • Facilitating scrum ceremonies or other meetings

In the end, one could argue that the goal of the Scrum Master is to make the team not need a Scrum Master. Therefore, not every team has an equal need to have one. The more mature a team is, the less the SM is needed.

Very importantly, a SM is not a person but a role. As such, the responsibilities can be taken on by someone other than a dedicated person whose title is Scrum Master. There seem to be three main ways to deal with the situation of not having a dedicated SM for the team.

  • Not have the role at all
  • One of the team members takes the role
  • The PO takes on the role

Let me elaborate.

Not having a Scrum Master

Not having a SM is an option, albeit not a great one for the vast majority of teams. Nevertheless, if the team is mature enough it can work.

As prerequisites, the team and PO need to be well versed in agile product development in and specifically in Scrum. They need to be able to resolve internal conflicts on their own. Most importantly, the team needs to be able to continuously deliver value without outside facilitation.

My guess is that less than 5% of all teams fit the description above. For those, the SM role does not need to be filled. For all others the SM is extremely helpful. In case there is not a dedicated person, the role needs to then be filled by someone else.

Team members as Scrum Master

When no Scrum Master is present, a frequent solution is for one of the dev team members to take on the role. This can be a single permanent person. The responsibility can also rotate from sprint to sprint between the different team members.

To make this work, the team members obviously need to be very well versed in all things agile. Also, the team members need to have the necessary skills. The competencies needed to be a great developer are very different from those needed to be a great Scrum Master. Communication, conflict solving, and leadership competencies are – in my experience – the ones lacking most often. 

As such, this set-up can be really hit or miss. I prefer that the SM responsibilities are taken on by someone that already has a role where similar competencies are needed, the PO.

The Product Owner as Scrum Master

This set-up is still far from perfect, but in my experience seems to work quite well. PO and SM have overlapping skill sets. Thus, it probably makes the most sense that the PO takes over the SM role. There are, however, a few things to consider in this set-up.

First, the jumping between roles happens constantly and sometimes (most of the time?) PO and SM have conflicts of interest. To give an exaggerated example, the PO would like to always add more to the sprint than any team can handle and the SM has to be the one to tell the PO what is actually possible. 

This is a conflict that needs to be resolved. Thus, the PO/SM needs to always be conscious which role he or she is representing at any moment. Not every PO is capable of handling this constant switching. (And that’s perfectly fine! There is a reason why the SM role exists!)  

Second, when a person has the roles of both PO and SM, undeniably some of the core PO work doesn’t get done as thoroughly as it should. In my experience, the PO/SM tends to increasingly focus on the day to day business. Important long term PO responsibilities generally get devalued. Working on the vision, talking to customers, and product discovery work seem to be the first things that suffer. 

These are some significant downsides!

To counter, it takes a dedicated effort and a great system for self organizing to balance the short term needs of the team to ensure short term delivery with the long term needs of the product to ensure long term success. This is hard! The more independent and self-motivated the team is, the easier this dual role is (as are all other aspects of PO/SM work). 

Other options

There are some other options to briefly touch on. A SM is a role that has a set of responsibilities. There is no law that these responsibilities need to be taken on by one person alone. The responsibilities can be shouldered by multiple people depending on their skillset. 

Say the team has an empathetic developer, another one that is well versed in agile and a PO that is very good at moderating meetings. The first developer could take on the responsibility of resolving conflicts, the second could be the agile coach, and the PO could lead the Scrum ceremonies as well as take care of impediments with Stakeholders.

All options can work but all are suboptimal. They all will have some negative effect. One person or multiple people are always taking on additional responsibilities. This will mean less time for the original work and on top less efficiency due to context switching.

Figure out what works for you

Scrum is a fairly rigid framework for agile product development – and for good reason. I strongly believe that it is ideal to always have a fully staffed Scrum team with PO, SM, and developers. 

However, the real world is generally messy and not at all like it should be. We need to somehow handle this. In case of a missing SM, I have had the most success when the PO takes on SM responsibilities. Thus, my advice is to try this approach first. 
Nevertheless, there are many ways to be successful –  even if the team set-up is not as it should be. As always, be pragmatic, see what works for you and the team, and adapt as you go. That is in essence the core of agile product development anyway.

Coverphoto by Ehimetalor Akhere Unuabona on Unsplash