7 Mistakes Every Scrum Master Makes, And What to Do About Them

When an agile or Scrum team isn't working well together, the problem might be mistakes you, as the team's Scrum Master, are making.

Mike Cohn, author of three best-selling agile and Scrum books, introduces 7 pitfalls Scrum Masters encounter, and explains how you and your team can escape them.

00:00 Introduction
00:35 The #1 mistake all Scrum Masters make
00:54 Two easy ways to break the opinion habit
01:44 The secret power of silence
02:12 Why telling is a good way to start but a bad way to finish
03:11 One way to know teams are becoming agile
03:16 One thing great Scrum Masters do for their teams
03:29 The worst thing you can do in a daily scrum
04:36 Why running a daily scrum is bad for teams
04:50 Why skipping Scrum meetings is a mistake
05:35 When to do Scrum by the book
05:46 When NOT to do Scrum by the book
06:00 The Scrum Guide is just a PDF
06:16 Stop treating every product backlog item as a user story
06:47 One of the worst Scrum Master pitfalls
06:55 Why you shouldn't insist teams finish everything every sprint
07:08 What happens when not finishing becomes a habit
07:38 How to solve the problem of rolling work into the next sprint

Let's keep the conversation going. What other common Scrum Master mistakes have you made? What's the worst mistake you've seen a Scrum Master make? Let us know in the comments.

Don't forget to subscribe so you never miss future tips on how to succeed with agile.

[AniaSzydowska-wmwl]

Thanks for the movie. Another common mistake that fits into what you've shown is being open to making mistakes. We often assume the role of people who know the answer to everything or should know it. We also want to protect the team from making mistakes

[RetroFab]

Another mistake I see scrum masters make is allowing themselves to becomes the team admin. Whether it be recording notes from meetings to updating Jira tickets for the team because they do not do it.

[Aries]

1. Giving the team solutions
2. Telling the team what to do, rather than selling
3. Running the standup
4. Skipping daily scrum or retrospectives
5. Don't take the Scrum guide as gospel
6. Thinking everything is a user story
7. Letting work roll from one sprint to another.

[GrefTek]

Hi Mike, thank you for this video. I would like to add one more to the list. Scrum masters allow a sprint review to be skipped because “they have nothing to show to stakeholders”. Sometimes because they failed to finish anything but sometimes because they are struggling how to present something technical (eg a new API end point)

[fouadbenzina]

Great video Mike.

I started working with a new senior team and am facing the 3rd point.

The team, based on its previous experience, believes that the daily scrum should be managed by the SM or TL.

I had a one-on-one conversation with team members to explain the philosophy why it is more convenient for the team to manage the daily scrum and not just by one person, but some of them are still not convinced.

For example, QA said it's up to the developers to run it, not us.

and it's true what you said, I feel like the team gives me the status and I'm there to inspect them.
so I lose the opportunity to be neutral and observe the team.

I still run it, and i involve the members who convinced and continue to work with others.

As for the other points, they are valid points.

Thanks for sharing this

[lukaszostatek]

hi Mike. I'd add to that list "not coming up with impactful actions during sprint retrospectives". It is easy for the team to become disengaged when actions from retros are not followed up or have low impact. Enough emphasis and time should be put during retrospectives towards coming up with good actions. Sadly this is the the mistake I've made in the past.

[daciamarkum]

I think a common mistake is thinking that we are there to protect the team from stakeholders. I would argue that we are there to minimize distractions and protect the sprint goal. But isolating the team from the rest of the business is more harmful than beneficial.

[andrzejklose]

I would add 2 more mistakes:
1. focusing only on the team, without trying to tackle problems at the organisational level. A ‘can't do’ approach limits the effectiveness of the team.
2. focusing on getting the sprint goal done and achieving the set PBIs, without caring for the continuous improvement of the team members and breaking down the competence silos between them. Sometimes we are afraid of lowering the velocity, without looking at the fact that a long-term increase in Bus Factor is much more beneficial.

[ashishdarji]

Another two major mistake based on my observation and inspection is :
1. SM is ignoring team feedback.
2. SM is failed to shield the team from outside disruptions during the sprint.

[WaqasAhmed-ubht]

Thanks, Mike, for the nice video you made. Some of the mistakes I used to make were skipping daily scrum and retros. Initially used to practice the Scrum guide as gospel. Not anymore :)

[jonno]

Love the new videos Mike!! Letting work roll forward is an interesting one, I regularly try not to do this but it always happens. There is no work remaining and there are 2 days left until the end of sprint. There's work at the top of the backlog but these won't be done in 2 days. What should happen? Bring a story into the sprint and expect it to roll over? Work on it outside of the sprint? Pick a small task further down the back log with lower business value? Would love to hear your thoughts

[rajeevm]

I would add Cargo Cult scrum to the list, basically on paper you are doing scrum and it's "ceremonies" but ignoring the underlying ethos of Agility. For example, micromanagement using JIRA.

[Rekettyelovag]

Number 7 is too damn common. And the funny thing is that it is usually advocated by the higher ups. There are places where goals don't matter because everything comes in directly from the customers (or customer contacts) w/o much though or design. Teams are conditioned to deal as much request as possible within the release cycle. People working there for 4, 5, 10+ years have a truly hard time to understand complex problem space, what RnD is supposed to be about, EBM, etc. No to mention that most of the time they just ignore you, especially if you are a young lad who just started work there or been there for a few years.
I tried to help people understand these concepts, but if they are not open and/or ignore studies and data, then I can't do much.

[hellglazer]

Our team tends not to invite the relevant stakeholders to the sprint review. I can tell them till I'm blue in the face that this an opportunity to get stakeholder feedback and to help us adapt for the next sprint. But now it just feels like I'm screaming in to the void. I often wonder if I should just request to leave the team since I cannot seem to sell the idea to them. We also have carryover every. Single. Sprint. No amount of explaining that we need to slow down goes particularly well. I'm fairly certain this all comes down to the cultural aspects within the organisation, and it's deeply frustrating when anything I say goes unheard.

[TheSmetanin]

What do you think when the team Invites PO to attend daily Scrum? Is it a good thing to do?

[nicktipton]

Acting as a liaison for the team to any stakeholders instead of empowering and encouraging ownership by the tean