Scrum is not particularly hard, but there are certain mistakes I see nearly every new Scum team make as they get used to a new agile way of working.
From letting work take more than one sprint to skipping retrospectives, these mistakes cause frustration and can severely impair a team,
keeping it from becoming as good as it can be.
Hi, I'm Mike Cohn, and I am the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil.
In this video, i'm going to share seven mistakes Scum teams will definitely make and what you can do about them.
The first mistake teams make is thinking their Scummaster is their manager.
Not true.
The confusion is natural because good Scrum Masters do perform some functions that good managers do as well, such as motivate and encourage people to do
their best work, look out for their mental health by avoiding excessive deadline pressure, remove impediments to progress,
improve a team's collaboration and teamwork, and more.
But Scrum Masters don't assign tasks or allocate people to projects.
Scum Masters doesn't pick due dates for tasks and projects, and most importantly, a Sc rum Master does not assume responsibility for a team's work.
That responsibility resides with the team members.
If you find your teammates acting as though the Sc Rum Master is their manager, discuss it immediately rather than waiting for retrospective.
Teams who view their Scrum Master as a manager are most prone to mistake number two, thinking the daily scrum is for the Scum Master.
I get it, the Daily Scrumb can easily be misinterpreted as just another status meeting, but it's not.
The Daily Scrumb is a synchronization meeting.
Team members talk daily, usually touching on progress since the last meeting plans for the new day, and any problems with which they would like help.
When thought of as synchronization meetings, it becomes clear that daily scrums exist for team members rather than the Scrum Master.
If you find your team directs their updates to the scrum master instead of to each other, stress the importance of the meeting in synchronizing work.
The third common mistake Scrum teams make is one that severely impairs the team's ability to be agile, expecting the product owner to tell them everything
before the sprint starts.
Most commonly, this shows up as the teams demanding the Product Owner provide full acceptance criteria for each product backlog item before that item can
be brought into a sprint.
This is a step back toward a waterfall or sequential approach because it essentially establishes a gate at the start of a Sprint.
No work is allowed through that gate until all open issues have been resolved.
To overcome this, team members need to become comfortable with uncertainty.
So do the product owner and business stakeholders.
When backlog items are brought into a sprint and open issues remain, there will be times when those items aren't finished in the sprint.
That's OK.
The alternative is slowing work down by trying to think of everything upfront.
The fourth common Scrum team mistake is wanting to work on big items that span sprints.
I can completely relate to this.
When I started doing Scum, some of my product backlog items were too big to fit into four-week sprint.
Over time, I learned ways to split that work into smaller pieces.
If I wanted to, could split those long-ago huge items into product-backlog items a team could complete in less than a day now.
When you're faced with something you consider too big to fit into a sprint, do three things.
First, try harder to find ways to split it up.
Second, if you don't succeed at splitting it, go ahead and let the item take two sprints.
Third, feel a little guilty about letting something take 2 sprint.
I include feel guilty as a reminder that you DON'T want this to happen too often.
I can promise you that finding ways to split work does get easier the more you do it.
Finding the patterns to spit the common types of work for your product is worth the effort.
Until you get good at splitting items, a large item might not easily fit into one sprint, as I just discussed.
But sometimes an item doesn't get finished in a sprint even though it was small enough that it should have been.
And this is common mistake number five, carrying items forward from sprint to sprint.
A real danger of this, is that is devalues the idea of the sprint A sprint should focus a team on achieving some goal every few weeks.
That means there should often be a little pressure as the deadline of the last day of sprint approaches.
I'm not talking about oppressive or stressful pressure.
Team members just naturally become more focused as end of a sprint approach.
It's similar to how I try very hard to catch up on email before a vacation.
When unfinished product backlog items are too readily moved into the next sprint, the team loses this sense of urgency.
If your team is making this mistake, a good way to correct it is to commit to far less work in the sprint.
Make sure the product owner is on board with this, and then add work to the Sprint when it becomes apparent the Team has capacity for it.
This allows a Team to feel the small win of adding work, rather than dropping it Thank you.
Perhaps the only thing worse than making these mistakes is not trying to correct them.
That is mistake number six, asking to skip retrospectives.
Sprint retrospective are the mechanism by which teams improve.
Setting time aside at the end of each sprint is extremely important, especially for a team new to Scrum.
If your team isn't doing a retrospect of every sprint, bring that up at your next retrospect, which better be at end the current sprint.
Some team members view the retrospectives as the only time they can bring up issues.
Absolutely not.
And the seventh mistake new Scrum teams make is not bringing up impediments early enough.
If something is slowing a team member down, you want to have that raised as soon as possible.
Most commonly, that means in the next daily scrum.
Some impediments, however, may be so important that they need to be raised immediately, perhaps via a messaging app or email.
Ensure everyone is comfortable raising issues as soon as they're discovered, hopefully before they become problems.
You want to avoid a shoot the messenger culture in which the person who raises the issue is blamed for it.
What other mistakes have you seen Scrum teams make?
Let me know in the comments, and I'll make some new videos on how to address some of those mistakes.
This video is part of a three-part series.
Be sure to check out the seven mistakes Scum Masters and product owners 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 will see you next time.