Is your scrum team not doing as well as you know it can?
From letting work roll forward from sprint to sprint, to taking the scrumb guide as gospel, many of the thousands of scrummasters I've worked with make
the same mistakes.
In this video, I'm going to share seven mistakes you'll definitely make as a scrhum master and what you can do about them.
Hi, i'm Mike Cohn, and I am the author of three bestselling books on Agile and Scrum.
I help teams succeed with Agil.
Let's dive right in with the first of seven mistakes scrummasters commonly make, and that is sharing your opinion too readily.
As a scrummaster, you want your team to own the problems and their solutions.
When you add your own opinion to readily, sometimes you shut down that conversation.
I definitely suffer from this problem.
Here are two easy things you can do that will help.
First, on your way into a meeting, tell yourself you will not share your opinion until one, perhaps two people have shared theirs.
No matter how good you think your idea is, commit to keeping your pie hole closed until some specific number of others have spoken first.
Second, when you ask a question, something like, how can we solve this problem?
Give your team time to think before you jump in with a solution.
All too often, I see Scrum Masters ask the team a hard question and team members do what they should.
They think about it.
But while they're thinking and before they can respond, the Scrum Master says, OK, maybe we should do this, or I guess we'll come back to that issue next meeting.
Silence can be uncomfortable.
When you ask a question, it can feel like everyone is staring at you waiting for an answer.
They may be staring at you, but they're thinking, just like you asked them to do.
Try counting silently to 10 before you say anything.
After 10 seconds, consider asking people to share what they are thinking or ask a follow-up question that may get them closer to a solution.
A second common scrum master mistake is telling the team what to do more than selling them on ideas.
Over time, good scrummasters change how they interact with their teams.
With a team that is new to Scrum, you may very well need to tell them to certain things.
You'll tell their sprint cannot be longer than a month.
No, they can't skip daily scrums or sprint retrospectives.
A team isn't very agile when you're having to tell them what to do.
But until they've gained some experience with Scrum, they may well rebel against things whose value they haven't yet learned.
With experience, teams become more independent, so that instead of telling them, you can sell them on ideas.
You can, for example, suggest they automate more tests or even begin automating at all.
You can try to sell them on the benefits of shortening their sprints.
Teams are truly becoming agile when you can switch from telling to selling.
And as a team progresses, you step back further.
Instead of selling them what you think are good ideas, You encourage and facilitate their discussions and pursuit of improvements they come up with.
A third common mistake by new Scrum Masters is running the daily Sc rum.
The daily scrum is a simple meeting.
Team members show up, discuss their progress, plans, and problems.
It helps team members synchronize their work.
Because it happens every day and has such a single agenda that is consistent from day to day, you don't need to run it.
Oh, sure, I'll run the dailies from the first few times for a new team.
I will announce that we're starting the meeting, then I call on one team member, ask them to share their update with everyone,
and then call the next person.
Finally, announce we are done.
But I want out of doing that as quickly as possible.
It's boring for me and boring the team, but it's not needed.
You want to get people to the point at which they show up and whomever wants to go first just begins.
Maybe team members report in a defined order, maybe the current speaker names the next speaker, or any other process.
The key is to get out of running the meeting yourself as soon as you can.
When the scrum master runs the daily scrumm, the meaning begins to feel as though it's for the Scrum Master.
the Meeting exists for team.
when they run it, it feels that way.
Still on the topic of the daily scrum, that meeting is also the source of a fourth mistake you may make as a new scrumbaster,
skipping daily scrums or retrospectives.
Just as new scrum teams may question the usefulness of daily scrums and retrospectives, so may new Scrum Masters.
But here's why skipping daily Scums or retrospective is the fourth mistake of new Scrum Masters The various aspects of Scum have all evolved to support
one another.
It may seem harmless to perhaps do daily scrums only two or three days a week, and when a team has sufficient experience,
I'll actually be open to hearing their argument for this.
I rarely agree, but as a scrum master, i'm open.
But early on, do scrumb by the book.
That includes doing a retrospective at the end of each sprint and doing it daily, well, every day.
While I suggest doing Scrum by the book when you and the team aren't new to Sc rum, you don't want to do that forever.
And this is the fifth mistake many Scum Masters make.
Taking the Scram Guide is gospel.
It's just a PDF.
As you in the Team progress, your experience should let you identify changes you want make, and it's possible some of those may go against what's written
in The Scam Guide.
That's fine.
Be careful deviating from it, but consider it.
The next common mistake, number six on our list, is thinking that everything is a user story.
User stories are great, I love them.
I wrote a whole book about user stories, but not everything on your product backlog needs to be a users story, so if you've encouraged your team to always
write as a type of user I want so that Stop.
Sometimes a simple statement is enough.
For example, upgrade the Linux server works great as a product backlog item.
The last common mistake is one of the worst, and that's letting work roll forward from one sprint to the next.
It's unrealistic to insist a team finish everything they start every sprint.
If you do, most teams will respond by very conservatively planning their sprints so they can finish.
But when a teams consistently fails to finish, the end of a sprint becomes an arbitrary meaningless date.
It arrives and team members just move work forward into the next sprint, no big deal, they think.
You want your team to instead think of the end of a sprint as significant.
Each time they finish what they said they would, they gain a little more trust from the business stakeholders.
That trust translates into an improved relationship.
To solve the problem of letting work carry forward, you need to break the team's habit of overcommitting.
Have them commit to what seems ridiculously easy in the next sprint, and then add to it later if it becomes clear they'll finish.
In this way, they'll feel what it's like to over deliver rather than to continually under deliver on what they said.
What other mistakes have you made or seen Scrum Masters make?
Let me know in the comments.
I read every comment and I plan to make new videos about some of the problems you mentioned.
This video is part of a three-part series.
Be sure to check out the seven mistakes product owners and teams make by clicking the links.
Don't forget to subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.