Do you want to be a good Scrum Master, or even a great Scrum Master?
I hope so. (Well, unless you’re a product owner or in some other role!)
I’ve spent over 20 years as a Scrum Master. Over that time, I’ve given and collected quite a lot of advice. I’ve distilled it down to the ten best bits for you.
1. Never Commit the Team to Anything Without Consulting Them First
As the Scrum Master, you do not have the authority to accept change requests (no matter how small) on behalf of the team. Even if you are absolutely positive that the team can fulfill a request, say, “I need to run this by the team before we can say yes.”
And certainly don’t commit the team to deadlines, deliverables, or anything else without first talking to team members. You may not need to talk to the whole team--plenty of teams will allow some or all members to say, “Yeah, we can do that” without a whole-team meeting. But it’s still their decision, not yours.
2. Remember You’re There to Help The Team Look Good
Being a Scrum Master is not about making yourself look good. Scrum Masters look good when the team looks good. And they look good when they do great work.
You know you’re doing your job well when those outside the team start to wonder if you were even needed. Yes, it can be scary if your boss wonders if you’re necessary. But a good boss will know that your skill and expertise make you appear unnecessary when in fact you are indispensable.
Trust your manager to understand the difference between looking unneeded and being unneeded.
3. Don't Beat the Team over the Head with an Agile Rule Book
Neither Scrum nor agile comes with a rule book (though some have attempted to create one).
If your product has users, consider writing user stories. But stories aren’t required to be agile. If someone needs to know when you’ll deliver: estimate. If not, maybe you don’t. If you think an end-of-sprint review is too late to receive feedback, do one-at-a-time reviews as each feature is built.
Being agile is about honoring the principles and values that create agility. If you stay true to those, you can’t go too far astray, regardless of what some may tell you.
4. Nothing Is Permanent So Experiment with Your Process
Part of honoring the principles of agility is to experiment with your process. Encourage the team to try new things.
Does your team love two-week sprints and think they’re working perfectly? Great. Now ask them to try a one-week or a three-week sprint and observe the results. Experiments might not always be popular, but they are the best way to ensure that you continue to uncover new, better ways of working.
5. Ensure Team Members and Stakeholders View Each Other as Peers
Team members and business-side stakeholders each bring an important perspective to a product development initiative. As such, each needs to be valued equally.
When either side views the other as something to be tolerated, the organization as a whole suffers. Development teams need to understand the unique perspective brought by stakeholders. And stakeholders need to respect the development team, including listening when developers say that a deadline is impossible.
6. Protect the Team, Including in More Ways than You May Think
Perhaps the most often given agile advice is that a Scrum Master needs to protect the team from an overly demanding product owner or stakeholders. And that’s good advice. Sometimes product owners simply ask for too much too often and too aggressively. This forces teams into cutting corners, usually quality corners, that come back to haunt the project.
And so a good Scrum Master protects the team against this.
But what you don’t hear as often is that a good Scrum Master should also protect the team against complacency. Good agile teams seek constantly to improve. Other teams settle, perhaps unconsciously, into thinking they’ve improved enough. And they likely are dramatically faster and better than before they’d heard of agile. But even great teams can often become even so much better.
Great Scrum Masters protect teams from ever feeling they’ve got nothing left to learn.
7. Banish Failure from Your Vocabulary
Every now and then I’ll visit a team that refers to a sprint as a “failed sprint.” Usually this means the team didn’t deliver everything they planned. I hardly consider that a failure, especially if the team finished most planned items or if they deftly handled an emergency.
When a basketball player shoots the ball toward the basket and scores, it’s called a field goal. When the player misses, it’s called a field goal attempt. Not a failure. An attempt.
Good Scrum Masters help teams adjust their thinking so that they recognize sprints and features that fall short of expectations as attempts rather than failures.
8. Praise Often But Always Sincerely
The other day I told my teenage daughter that I was proud of her. Her face lit up. That shouldn’t have surprised me. Who wouldn’t like to be told someone is proud of them?
But the way she reacted made me realize I must not tell her this often enough. I thought it was equivalent to me telling her something obvious, such as, “You’re tall.” But I learned it wasn’t.
Don’t ever offer false praise. No one wants to hear that. But when your team members do good work, let them know. Chances are, they aren’t hearing it often enough.
9. Encourage the Team to Take Over Your Job
A team that is new to agile will rely on their Scrum Master or coach in significant ways. The team may not know how to keep daily scrum meetings under fifteen minutes. Or they may not understand the importance of overlapping work or of being a cross-functional team.
The same is true of a an inexperienced sports team. The coach of the little kids learning to play football (soccer) needs to teach them everything. When my daughters were 6, their coach would run along the sideline the entire game yelling, “Kick and run!” If he didn’t, the young players would forget. Even with him yelling, occasionally some kid would just sit down on the grass and stare.
Contrast the coach of the young kids with the coach of a World Cup team. On a World Cup team, players have learned what to do. If the coach is late for practice, the players will know what drills or exercises to start the day with. The World Cup coach doesn’t need to remind the players to kick and run. But the World Cup team would never tell you they don’t need a coach at all.
No matter how good an agile team gets, I still think they benefit from having a Scrum Master or coach. But good agile teams take on some of the more straightforward coaching tasks themselves as part of their own journeys to mastering the skills needed in product development.
10. Shut Up and Listen
Some of the best coaching or mentoring you’ll do is to stay silent and let the team figure out the answer.
This can be hard. When you see your team struggling to figure out what to do, it’s natural to want to jump in and offer advice. But if you solve problems or even offer suggestions too readily, team members learn to just wait for you to solve every problem for them.
I don’t want to imply you can’t ever offer suggestions. You’re a smart person. If not, you wouldn’t be in the role you’re in. But part of being a great Scrum Master is helping teams learn how to solve problems on their own. If you solve every problem team members face, they don’t get a chance to learn how themselves.
