Scrum Masters – First, Do No Harm
Scrum does not mean disrupt the team, it means serving the team's best interest by providing just the right amount of support.
Join the DZone community and get the full member experience.Join For Free
Some Scrum Masters are doing more harm than good to their teams. The phrase “First, do no harm” paraphrases a portion of the physician's Hippocratic oath: “I will, according to my ability and judgment, prescribe a regimen for the health of the sick; but I will utterly reject harm and mischief”. Similarly, Agile Scrum Masters must, to the best of their ability, prescribe a regimen for the health of the team; but they must utterly reject harm and disruption.
Scrum Masters can do harm by doing too little or too much for the team. Someone who just schedules meetings, takes notes, and brings the team coffee is not a Scrum Master. The Scrum Master is a servant-leader to the team – not just a servant, but also a leader. It’s easy to see the problem of a Scrum Master doing too little for the team, but how is doing too much harmful?
Servant leadership is about serving others. However, serving others oftentimes means helping them learn to do more for themselves. As a Project Manager for 15+ years, I led teams of up to 50 people on high profile, mission critical projects. Being responsible for planning, directing and tracking a bunch of people’s effort can be a power trip. That is not what Agile is about. Ken Schwaber, co-developer of Scrum, says this – “A Scrum Master is responsible for getting work done through others – they are not responsible for making sure what they think should be done is done”. That’s a very subtle but important difference.
A Scrum Master with a “command and control” style doesn’t work well. “Command and control” and “servant leadership” have widely different approaches and desired outcomes. Command and control creates powerless teams. As one Agile Principle states: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”. Another states: “The best architectures, requirements, and designs emerge from self-organizing teams”. Self-organizing includes experimenting with approaches that the team thinks may help them adapt to challenges, not just relying on the Scrum Master to fix everything. The Scrum Master “fixing everything” is a harmful behavior. The intent is good, but the outcome can be disastrous. The Scrum Master helps remove impediments and protects the team from outside distractions, but the team also needs to become more self-reliant.
So How Does the Scrum Master Help the Team Learn to Do More for Themselves?
- Don’t assign work to team members. Teach them to pull work themselves from the product backlog and collaborate to define the sprint plan.
- Instead of repressing conflict, guide team members through healthy conflict resolution so they become better communicators and teammates.
- Don’t perpetually write user stories for the Product Owner. Assist them early on with their first user stories, then become a coach to them.
- Don’t be the team’s “gofer”. Teach them persistence and effective follow-up so they get better at removing impediments themselves. Every impediment “hand-off” eats up time.
- Take advantage of every opportunity to teach better collaboration skills. Never communicate “for someone”; teach them to communicate with others face to face instead of emailing or texting, then help them continually improve their communication skills.
- Allow the team to make mistakes, then help them learn from their mistakes. Lessons are often better learned from failures, than from being protected.
Finding the right balance between protection and “tough love” can be challenging for the Scrum Master. But it’s so important for the team to be able to think on their own – to challenge the status quo – to not be satisfied with “good enough” but push to become great. No one person has all the answers – not even the Scrum Master. Embrace collaboration, trust, reflection and adaptation, to empower your team.
So first, do no harm. Then provide a regimen for good Agile health, and watch the team get better.
Published at DZone with permission of Dwight Kingdon. See the original article here.
Opinions expressed by DZone contributors are their own.