- Ownership - A great scrum master is someone who feels a strong sense of ownership and pride in their work and the work of the team. They strive to always make sure that the team is staying on top of done-ness criteria, stories, grooming, etc. They see dependencies, impediments and obstacles and they work cross-functionally and with their team to address them. They are diligent at daily scrum, asking questions and making sure everyone is there and ready to contribute.
- Leadership - A great scrum master knows when to let the team step in and drive a situation and when to take more of a visible role in driving the team. This depends a lot on the team and experience level of the scrum master. For example, if the team has a strong natural leader already on the team, the scrum master can be there to address dependencies and let the team shine. On the other hand, if the team is constantly struggling or has been known to be underperforming, a more active leader/mentor type of role from the scrum master may be necessary.
- Appreciation - A great scrum master gets along with the team. They know when a moment of levity is needed or when the team needs a little bit of a breather. They understand and appreciate the efforts of everyone on the team and work to foster and build great relationships.
Scrum Master Traps
- Overbearing - I've seen scrum masters publicly "beat" up a team member for making an honest mistake. This is a tough trap to avoid, you have to know when to push and challenge without being overbearing or causing fissures in relationships. I've seen other scrum masters force the team into behaviors they don't want or are not bought into because that's what some agile book suggests. Once the scrum master starts to become overbearing, it becomes harder and harder to earn the team's trust and respect and regain their ability to influence.
- Too Protective - This is a common mistake. (especially when the scrum masters report in to the same managers as the developers). In this case, the scrum master fails to act as an impartial leader and gives the bad actors on the team free reign to frustrate others. Another example, is when they don't challenge the team to improve or don't address a situation where the team could have performed better. If a scrum master (who is part of the team) is silent at a retrospective, that's probably a sign that they are too protective :)
In my view, the key to a great self-managing team is this constant ebb and flow of feedback and information. When there is an imbalance or the team is starting to head down the wrong path, the scrum master should let the team try and self-correct without letting it get too far. Trusting the team, but still knowing when to step in is something that will take time as the scrum master gets to know the team.