“Can a Development Team member be the Scrum Master?”

This is a common question in my Professional Scrum classes. It often comes up early when we are still learning the basics of the Scrum framework. And it comes up because people are already wearing two hats or are being told by their organizations that they will be.

The short answer is: Scrum does not have a rule against fulfilling multiple roles. This is left up to you to decide what is best in your context.

The longer discussion involves answering the question: Should you and can you fulfill both of these roles?

Often this situation arises from a desire to select someone from an existing Development Team to also be the Scrum Master. Organizations generally don’t like to “add headcount” unless they have compelling reasons. And while there is nothing inherently wrong with that approach, it is important to look for someone who has the skills, traits, knowledge, and experience desired in a strong Scrum Master.

To answer our bigger question (should you and can you), let’s explore the 4 most common challenges I see when a Development Team member also fulfills the Scrum Master role.

Challenge #1: The Scrum Master’s full impact and responsibilities are minimized.

First, let’s get clear on the accountabilities.

  • The Development Team is accountable for creating a releasable product Increment at least by the end of every Sprint.
  • The Scrum Master is accountable for ensuring everyone understands and enacts Scrum, helping them more effectively fulfill their roles and achieve the benefits of an empirical process.

A Scrum Master serves the Product Owner, the Development Team, and the organization – this is a wide range of responsibilities. If a Scrum Master is perceived by the team and/ or the wider organization as just an “event facilitator” or “Scrum enforcer,” the impact of the role and ultimately the benefits of business agility are diminished.

Teaching is more than a lecture. Coaching is more than powerful questions. Facilitation is more than running a meeting. And knowing what approach to take and when to best serve a team is very challenging, even for experienced Scrum Masters who are completely focused on the role.

Teams and organizations need to recognize that if this person does not have Scrum Master experience and skills, they will need support to grow their capabilities (e.g. training, coaching, mentoring, etc). This will require time and commitment and take away from the time they spend on building the product, which leads us to the second challenge.

Challenge #2: Focusing More on Doing the Work

There is often pressure in the organization to “deliver more.” In addition to organizational pressure, the person’s passion may simply be more aligned with building the product rather than servant leadership.

When either of these is true, it is going to be very challenging for this person to muster enough commitment and carve out enough time to improve in the Scrum Master role. And even if the person has a strong passion for the Scrum Master role, everyone else will need to respect that and give this person the time and support they need.

This means the Development Team will likely need to adapt themselves and how they work in order to address the next challenge.

Challenge #3 – Capacity Planning and Scarce Skills

It’s hard to know exactly how much time is needed to be a servant-leader, enabling and supporting the Scrum Team and the organization while removing impediments that arise. It is also hard to know exactly how much time is needed to build a complex product that meets the Sprint Goal and a high bar of quality and completeness.

Both the Development Team and the Scrum Master are doing complex work!

When a Development Team member is also the Scrum Master, the rest of the Development Team will need to be more flexible and less dependent on this one individual to build the product. This often requires a redistribution of the development/ delivery knowledge, skills, and activities.

This takes time to unfold, so it is important to be having open and honest discussions about the needs in Sprint Retrospectives, as well as in day-to-day collaboration.

Challenge #4: Confusion with authority, ownership, and self-organization

A Scrum Master will need to be mindful of respecting the shared accountability and ownership of the entire Development Team. Scrum Masters are often seen as the “expert” and a position of authority. But one must be careful to remember that the authority and expertise of a Scrum Master is over the effective use of Scrum to enable empiricism and healthy team collaboration. It is not an authority over how best to create a releasable Increment and how much work to take on in a Sprint.

In this situation, a Scrum Master must be observant of complex team dynamics, which may be operating at a subconscious level. As a Development Team member, the person has input into how the work is done and an accountability for quality and completeness. And as a Scrum Master, the person wants the entire Development Team to feel accountable for creating the Increment and empowered to decide how best to do the work.

Enabling and growing self-organization becomes even more challenging.


So should you and can you? First, have an open discussion about these challenges. And then ask yourself why you want a Development Team member to also be the Scrum Master.

If it is simply to save money and/or because one role is not viewed as equal in importance, this is pointing you towards the underlying problems to address. If you have uncovered other reasons that feel valid and important, then perhaps combining the roles does make sense in your context and is worth trying. Be sure to frequently discuss how well this is working.

Do the best you can to set individuals, Scrum Teams, and organizations up for success.