I've been a Scrum Master for a couple of years now, and during that time I've been involved in a few different teams, each with different challenges.

This is an account of the challenges I've faced, and some possible solutions for those.

The Scrum Master is responsible for delivery

This is quite common, and is usually an issue in traditional "waterfall" companies, who venture into the world of agile development. The cause usually is the old command-and-control style leadership that defines traditional companies, in which having a single person accountable for a project, makes management simpler and more comforting.

Why is this a problem?

  • In the normal sense, the Scrum Master will ensure that developers deliver the issues according to requirements (ie. is the feature meeting the definition of "done" ?). When responsible for delivery, he will be tempted to look the other way, ignoring the quality of work delivered.

  • If the Scrum Master also has a part in actually delivering the parts of the project, he may focus on delivering the product, before ensuring that the development process is running as it should, to deliver the best possible product. This may also lead to the next point below.

How to avoid this

Have a strong P.O. Avoid "owning" the product, by being the single person who knows most about a products needed features.

Try avoiding taking responsibility of planning projects. Planning (and the related commitment) is a team issue, and it needs everyone to agree on commitments, to ensure best understanding of goals and how to get there.

The Scrum Master becomes a manager

This issue usually appears during the Daily Scrum. The beginning sign of management-symptoms appear when team members start by talking directly to the Scrum Master, when reporting what they did yesterday. Also, if a team member starts to only report what they did yesterday, and stops afterwards, this also indicates that the team may not know how to proceed.

Why is this a problem?

One of the key principles of Scrum, is that the team is self-managed. This means that the team decides on the best approach to solving obstacles and make decisions on how to ensure delivery as best possible, to not rely on a single individual.

Possible causes

  • Weak goals set for the team. This may be caused by extended periods of "maintenance-work", in which the team only delivers small features or bugs indifferent to the Product Owner.
  • Indifference on the product. The team doesn't feel the commitment towards delivering the best product.
  • Lack of knowledge on how to proceed work on a product.

How to avoid this

If a team member keeps looking at you during Daily Scrum, start moving around. Avoid eye contact and if all else fails, move behind the person. Team members report to each other, not the Scrum Master.

If team members start to not mention what they are going to work on for today, either keep silent, see if the other team members remind them or, if the next person starts talking, interrupt and ask the person to finish first.

The Scrum Master makes decisions on behalf of the team

Let's make this clear: The Scrum Master owns the process, NOT the team.

In a lot of cases, Scrum Masters are selected by experience (Usually, senior developers and team leads are primary candidates) and by personality (You need both communication skills and the rigid mind of a mainframe developer to keep the process on track). However, this also causes team members to turn to the Scrum Master to make decisions for them.

Why is this a problem?

  • The team should never depend totally on a single individual.
  • Most teams are made up by a variety of different personalities. Getting opinions from everyone, will ensure a better analysis of any issues, and will deliver the best solution.
  • Dictatorship is bad. It causes poor teamspirit and a lack of involvement among members.

How to avoid this

Always take large decisions that affect the product and delivery, to the team.

Ensure that everyone is heard during the decisionmaking process.

Next up

This was a few observations I've done the last few years, and your experience may differ. Next time I'll write a bit about figuring out how you're doing, and how to improve your process.