The main goal of the Scrum Master is to create a highly productive team that is self-organizing and continuously improving. They do this by acting as a servant leader, coaching the team when needed, and creating the space for team members to own their work, their decisions, and the opportunities for self-improvement.
Many Scrum Masters act in the dark side. Often because that’s how their organizations define the role, other times because they feel the urge to step in and “help the team”. When these things happen, the role of the Scrum Master is diminished and the ability of the team to grow as a productive and self-organizing team is compromised. Let’s look at some common anti-patterns:
Thing that Scrum Masters often do – and they shouldn’t
The Scrum Master is the one updating cards in Jira, adding details, and assigning tasks to team members
When the team changes how to do the work, the Scrum Master interjects and tries to correct them immediately, instead of letting the team try a new way
The Scrum Master facilitates the Daily Scrum by deciding who speaks, when, and how much
The Scrum Master jots down what is said at Daily Scrum and later emails a status report to everyone on the team to summarize decisions taken and update who missed the event
The Scrum Master measures team metrics and provides status or progress updates to external stakeholders
The Retrospective is just another meeting rather than an opportunity for the team to find ways to improve and then add actions items to the backlog
The Scrum Master sweeps conflict and problems under the rug by not using Sprint Retrospectives to address those openly.
Scrum Master tips
Effective Scrum Master create such an effective team that they are no longer needed and can move forward to another team. A few things Scrum Masters can do:
Do not touch the work. Let the team members update cards in Jira, refine acceptance criteria, check Burn-down charts for status, move cards on the team board, etc.
Let the team fail at times and guide them in Retrospective on ways they could improve
Facilitate events by creating the space for the outcomes of the event to happen but without guiding every action in it
Step back from guiding the Daily Scrum. Let the team self-manage it on their own. Use the Retrospective to discuss ways for the team to make it more effective.
Do not attend the Daily Scrum, and later ask the team how it went. Or participate by dialing-in, and don’t say anything to observe how to team self-organizes.
Coach the Product Owner/Manager on things they can do better to support the team (e.g. context about User Stories, availability for testing, access to customers for discovery, etc.)