ScrumMasters: Don't be a Fixer
Join the DZone community and get the full member experience.Join For Free
Discover how to increase change awareness, code quality, and maintainability through straightforward code reviews, with a simple, lightweight workflow, brought to you in partnership with JetBrains.
I think one of the best aspects of agile development is the ability for a team to frequently learn from their mistakes. It's especially crucial that this happens in a blame free environment. When something goes wrong during an iteration, it's important that no team member is singled out. The entire team accepts responsibility for their failures and successes together. And when a team makes mistakes, they need to learn from them. The key components for in a team's ability to learn from their mistakes are the attitude and interactions of the ScrumMaster.
There are a few things a ScrumMaster must do to help their teams learn from their mistakes. First and foremost, the ScrumMaster cannot be a fixer. When things are broken or not working the team, not the ScrumMaster, must figure out how to fix things. If the ScrumMaster continually steps in to fix the problem, the team never learns how to fix a problem for themselves. This leads back to the old command and control structure of more traditional development approaches.
Instead of being a fixer, the ScrumMaster needs to be an enabler. The ScrumMaster needs to be aware of any problems the team may be having and provide them with whatever resources they need to solve the problem on their own. It could be something as simple as a phone number for a key client contact. Whatever it is that is keeping the team from solving their problem, the ScrumMaster is there to provide it...except for the solution itself.
The other thing I think a ScrumMaster must do is allow teams to make mistakes. Because Scrum is, at its core, an empirical process, we expect certain things not to work...and we expect to inspect and adapt our practices to make them work better. That means letting teams fail sometimes. If a ScrumMaster always steps in and prevent a team from making mistakes, the team never get the chance to learn from them. If a team doesn't get that chance, they become inefficient at self-management, another key tenet of Scrum. And again, this leads back to the old command and control structures of traditional project management.
So, my two pieces of advice for ScrumMasters: Let your teams make mistakes...and don't be a fixer, be an enabler.