Scrum masters and the Agile framework—first, do no harm
Some scrum masters are doing more harm than good to their teams. The phrase “First, do no harm” paraphrases a portion of the Hippocratic Oath taken by physicians: “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.
The role of a scrum master
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 imagine how a scrum master might do too little, but how is it harmful to do too much?
Servant leadership is about serving others. However, serving others often 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 the 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.
Why command-and-control doesn’t work
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.” Says another: “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, which 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.
Here’s how the scrum master helps 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.
- 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. Instead 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 those 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.
The Agile development methodology is an integral part of making digital real. Learn more in our new e-book by completing the form below.