Five common pitfalls for Scrum Masters and how to avoid them

1. The Scrum Master as police agent of Scrum rules instead of team coach

Especially beginning Scrum Masters in inexperienced teams often see their role as police agent of Scrum rules. For example: how to act if team members don't want to do the Daily Scrum (a.k.a. stand-up meeting)? A 'police agent Scrum Master' will then primarily think about how to get the team members to do the Daily Scrum. But experienced Scrum Masters don't act before gaining a deeper understanding of what causes this behavior.

What might be the reason if team members don't feel the need for a Daily Scrum to coordinate teamwork? In many cases, team members feel only responsible for 'their own' individual work instead of for the teamwork. And, digging deeper, what might be the reason for that? It might be that the team does not have a clear and inspiring shared purpose. Or the way line managers evaluate performance is inconsistent with what is needed for people to behave as team players.

Whatever Scrum rule is violated, an open discussion in the team about underlying concerns is a much better starting point than just trying to enforce the rule.

2. Coordinate teamwork instead of helping to improve self-organization

Scrum Masters are often seen as coordinators of teamwork. But instead, a Scrum Master should help a team to organize work so that no coordinator is needed. This is a common pitfall for Scrum Masters who were previously team leaders or project managers in an organization where people are used to be assigned tasks.

If people are used to getting tasks assigned and this suddenly stops, initially the work will not get done smoothly. But teams need to go through this to get better in self-organization. Good Scrum Masters help to speed this up by frequently helping their team to inspect how things went and to adapt based on what is learned. Does everyone understand all the work that the team is responsible for? Is the status of the work always clear to all? Do people openly speak about problems they face? Do people then step in and help? Scrum has Retrospectives to discuss how to improve these things.

3. Only address what can be solved within the team, but not what needs to be addressed in the wider organization.

Many Scrum Masters pay too little attention to problems that can't be solved within the team. In many cases the Product Owner is saddled with such problems. But it is the Scrum Master who is supposed to focus on HOW the team can deliver value to stakeholders, so that the Product Owner can focus on WHAT the team should deliver. For this, the Scrum Master also needs to focus on the wider organization and not just on the team itself.

Especially in bigger organizations, teams often have blocking external dependencies. An example is a software development team that needs a small change in IT infrastructure, such as opening a firewall port. Many Scrum Masters reason as follows: “The problem can’t be solved within the team. It needs to be solved by stakeholders. This makes it a Product Owner concern.” But it should be the Scrum Master taking the lead in getting the firewall port opened by whoever can do it. The team can also be helped to identify such external dependencies earlier. And perhaps in the long run, more responsibility for IT infrastructure can be taken on by the team itself. The Scrum Master can take the lead in planning the education and automation that is required to make this possible.

4. Insufficient focus on getting work fully Done

In Scrum, a team focuses on a limited amount of work that can be completed fully within a short time frame (a Sprint). This is easier said than done. In many organizations, before moving to Scrum, everyone is very busy, but little gets done. Many projects are done in parallel, people work on several projects at the same time, work is not progressing because it waits for something that needs to be done by another department etc. Therefore, we’re used to have much work in progress that is not fully done.

Getting better in finishing work items fully in short time-frames is a learning process for a team and it requires a lot of discipline. Novice software development teams typically don't get new functionality fully tested and bug-fixed before the Sprint ends. Effective Scrum Masters help their team to improve on getting work fully 'Done', without leaving loose ends like bugs or technical debt.

5. Insufficient attention to long-term improvements

Initially many improvements in a team can often be implemented quickly. It is for example easy to agree on the Daily Scrum to be 30m later so that all team members can make it on time. But after a while, many important improvements can't be done in a single step. Scrum Masters need to help their team to identify longer term goals for improvements and then help to take small steps forward.

A common example in software development teams is test automation. Test automation is an important practice to be able to continuously get new functionality Done without breaking what already worked. In many cases, there is already a large existing system and developers will indicate that it would be a huge amount of work to automate tests for it. Unless a Scrum Master helps, often time never comes to take a first step at it. A good Scrum Master would first help a team to identify the importance of test-automation in the long run. And then help to identify a strategy for implementing test automation in small steps. A typical first step would be to automate only a single test in the next Sprint for the most commonly used functionality.

If you want to learn more on how to become a great Scrum Master, come to one of my Certified Scrum Master trainings!

https://scrumtrainingcoaching.com