Scrum teams work on complex problems. Solutions emerge during these type of projects; over time and after many sprints. When a scrum master becomes the “hero” and mandates solutions, he/she can cause lasting damage to the scrum team.
All nighters, caffeine fueled coding marathons, and last minute deployment heroics happen regularly on projects death marching to a forced conclusion. That behavior manifests on agile teams as well. But the “hero scrum master” anti-pattern surprised me during a recent exchange on LinkedIn.
A scrum master explained his role as follows:
“I would prefer to be considered as someone who managed to make the team get past the hurdles and obstacles and make it to the “Miller Time” to chuckle and laugh about how silly they behaved in reflection.”
Not exactly the model statement for self-organization and self-management.
My own struggles with dropping the command and control habit are here and here. During those episodes I thought I acted in the best interest of the team and with best intentions. And I believe that this scrum master feels the same about his actions.
With that said, the consequences of directing instead of coaching can be significant and long lasting:
- No Ability to Experiment: When a scrum master “solves” all of the teams problems, the scrum team will not learn how to experiment. We constantly inspect and adapt our practices. Some changes work; others don’t. Dictating answers robs the team of these possible improvements and lessons.
- Scrum Team Members Withdraw: Apathy sets in when scrum masters mandate solutions. A disengaged team can lead to silos of knowledge and individual actors as opposed to a gelled and cohesive scrum team.
- Whole Team Concept Compromised: Every member of the scrum team contributes to and owns the project. If a hero scrum master is solving all of the problems, the scrum team can become dependent on this hero behavior. Coaching others to solve issues and impediments can help make sure that teams grow, mature, and find success together.
WHAT CAUSES HEROIC SCRUM MASTER BEHAVIOR?
As the LinkedIn exchange progressed, it became clear that a bad system/environment drove the scrum master’s behavior:
- Job Security: When I asked why the heroics were needed, he replied “Either one is a passionately participating and involved scrum master or he is someone that can be replaced tomorrow and no one may notice any difference.” Understandable, but not in the spirit of servant leadership.
- Carrot and Stick Mentality: He also added, “Sounds to me more like letting people succeed or fail but suffer so they can change out of necessity at the cost of damaging the team’s image/pride and team spirit. This to me is something a villain would resort to.” Experiments do not appear to be valued at his company. Neither does failure.
- Bad Scrum: The scrum master’s environment “smelled” toxic. The scrum team does not have a Product Owner. The QA team works in India and gets code nightly from U.S. based developers. The list goes on. Perhaps, without the heroics of the scrum master, nothing truly would get done at his company.
The scrum master heroics can appear to help in the short term, but over time the negative impacts – especially the loss of continuous improvement – amplify. The sprint retrospective can help uncover these issues. But once these items make the impediment list, the scrum master still has the difficult task of addressing these system issues up the organizational structure.
Being a servant leader is hard, but as the consequences above indicate, we should coach our teams to be empowered and self-sufficient and remove system impediments…even if it makes us a bit uncomfortable.