It’s well established that there are exactly three roles in Scrum: Product Owner, Scrum Master, and Development Team. Often, there is a natural desire to merge the role of Scrum Master with another role on the team. Should you do this, though?
The answer, as is so often the case, is it depends on your team.

Combining the Scrum Master role with a member of the Development Team for many feels like the most natural approach. This keeps the Scrum Master not only embedded with the team, but already an integral part of what the team is doing from day to day. This can work under the right circumstances, but it short-changes the role of Scrum Master. If the SM/Dev is spending the majority of his day writing code or involved with testing, does he have a chance to truly take in everything that is happening with his team? How effective can he be at removing impediments? It’s hard to function as a true servant-leader when you are a peer with the other members of the team.

What often happens when a member of the Development Team takes on the Scrum Master role is that the team starts to do Scrum in name only. The events are performed, but there is typically little variation in how they take place. The Scrum Master often lacks the authority or will power to push the team beyond their perceived limits, and will be happy with the status quo. The ability to truly act as a change agent for the team and the organization can be restricted when wearing both hats at the same time. For some teams, especially mature teams, this is all perfectly okay.

Combining the role of Scrum Master with that of the Product Owner, however, is perilous, as the two roles are designed to balance each other out in many ways. The Product Owner wants to deliver maximum value with every Sprint, the Scrum Master wants to make sure that the team doesn’t over-commit when forecasting. The Product Owner often sees the Daily Scrum as a change to get the status of every Backlog Item in the Sprint, the Scrum Master knows this is a planning meeting for the Development Team, and status updates are not necessary outside of that context. To put both hats on the same person creates a conflict and should be avoided.

Remember the responsibilities for each member of the Scrum Team: What, How, and Process. When you combine the Product Owner with the Scrum Master, you are giving her power over what the team works on and the process through which they accomplish it. That’s a lot of power resting on one person’s shoulders, and it will hamper the Development Team’s ability to decide how they are going to work.

None of this means you can’t merge the roles. You can, and it might even work best for your teams. It’s important, however, to think through exactly why you feel the need to merge the roles together, and what benefit you are immediately gaining by doing so. Scrum has an innate system of balance in place between the three roles, and any time you double up a role with someone, you risk upsetting that very balance. Consider the possible outcomes carefully and make the correct decision for your team.