Ten sentences with all the Scrum Master advice you’ll ever need

Ten sentences with all the Scrum Master advice you’ll ever need

Do you want to be 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. You 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.

What’s Missing from this List?

I’m sure I’m missing some pearls of wisdom. What is some of the best one-sentence advice you’ve received or given as a Scrum Master? Please share your thoughts where this post was originally published, on the Mountain Goat Software blog.

If you liked this article, you can sign up to receive my one best, short tip about agile each week. These tips aren't online and signing up is the only way to receive them.

Matthew Drain

Team Lead Global Release & Change Enablement and Global Change Product Owner

5 年

Thanks for sharing Julio E. Ruiz-Duran!

回复
Ziryan Salayi

CEO of Scrum Professionals - Organization Agility Coach

6 年

Nice advice Mike Cohn, thank you. I'd also like to add "love the team, but don't get lost in them. Help the organization become Agile as well"

Jussi Ranta

Software Development Professional

6 年

This article was a real eye opener for me, even if I did had similar approach in my short scrum master career. This article is still very helpful for anyone in a leading position. Thank you!

Cathy Ogle

Agile Portfolio Lead

6 年

Thank you Mike! All scrum masters should read this.

Nir Makmal

Principle Research Architect | M.Sc, CS | AI/ML/GenAI | Data | Security | Fintech | Speaker | Innovation

6 年

Great list, I also believe and contiue building Self managed and skilled agile teams, this puts the the team and the company in the top and enable the company expansion... "...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."

要查看或添加评论,请登录

Mike Cohn的更多文章

  • You Don't Need a Complicated Story Hierarchy

    You Don't Need a Complicated Story Hierarchy

    Consultants and tool vendors seem to have a penchant for making things complicated. It seems the more complicated we…

    7 条评论
  • Agile Teams Need to Balance Specialists and Generalists

    Agile Teams Need to Balance Specialists and Generalists

    There's a mistaken belief that to be agile, every team member must become a generalist. What I find surprising about…

    28 条评论
  • Product Owners: Quick Action Isn’t Always the Right Course

    Product Owners: Quick Action Isn’t Always the Right Course

    I’ve been doing a back-to-basics tip series, exclusively for my subscribers. This past month’s weekly tip focus has…

    14 条评论
  • With Agile, It’s Not What You Do. It’s What You Do Next.

    With Agile, It’s Not What You Do. It’s What You Do Next.

    I’ve been writing a series of tips about product owners, exclusively for my subscribers. It got me thinking about the…

    6 条评论
  • What Happens When During a Sprint

    What Happens When During a Sprint

    Successful Scrum implementations involve a handful of important sprint events (also called sprint meetings or sprint…

    2 条评论
  • What Are Agile Story Points?

    What Are Agile Story Points?

    Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully…

    14 条评论
  • Don’t Equate Story Points to Hours

    Don’t Equate Story Points to Hours

    I’m a huge proponent of estimating in story points. (You can get a full overview of how to use story points from…

    49 条评论
  • Epics, Features and User Stories

    Epics, Features and User Stories

    I’ve been getting more and more emails lately from people asking, “What is an epic, a feature and a user story in…

    6 条评论
  • Nine Agile Halloween Costumes for Scrum Teams

    Nine Agile Halloween Costumes for Scrum Teams

    It’s time to start thinking about an appropriate costume you can wear to the many agile-themed Halloween parties you’ll…

    4 条评论
  • 5 Ways to Split User Stories: The SPIDR Method

    5 Ways to Split User Stories: The SPIDR Method

    Splitting user stories. It’s something I get asked about every day.

    45 条评论

社区洞察

其他会员也浏览了