We see ScrumMasters fail very often while supporting agile teams in their agile transformations.
Based on stories of more than one hundred of ScrumMasters we think that following 10 ScrumMasters failures are the top most important for agile teams.
1. Because of Agile
People do not care about Agile or Scrum. They want a purpose, mastery and personal growth. Offer them agile principles as help which allows achieving their goals!
ScrumMasters too often use words Agile, Scrum, Kanban. They too often explain that you have to do that and that because of Agile. That is not the answer. Scrum is just project management tool. Agile is just a mindset.
Agile should help achieve something more important. The company goals and personal goals as well.
If Agile nor Scrum do not help to achieve these goals, people will be resistant to apply them.
Team members in such teams very often do not want to do Scrumdaily standups. They hate sprint plannings too often. Retrospectives? No way. Because for them it might be just another process regardless all of the benefits which Agile or Scrum brought. Some people need time to understand them.
But saying words Agile, Scrum too often will not make the problems disappear.Agile, scrum, agile, scrum, agile, scrum.. See that?
Think about following questions:
- What do you want to achieve?
- How does the situation look when everything is done?
- What might block you to get there?
- Whatdo you need to do to get there?
- How will you know you are there?
Im pretty sure you will find a lot of tools in Agile or Scrum. There are dozens of practices like product grooming, release planning, sprint planning, user story format, Kanban boards, burndown charts, velocity, capacity calculation, fantastic retrospectives.Connect agile practices to 5 bullets mentioned above and people will participate.
You dont manage people. You help to improve a system of work, a culture of a company and remove blockers.
ScrumMaster is not a job role. ScrumMaster title is not a rank.
ScrumMastership is your badge while youare onthe duty.
As ScrumMaster, you are with people to help them do their job. To provide them what they need ahead, before something will become a problem, the blocker. You are there to communicate with the management aboutthe impediments that team is not able to solve on their own.
Good ScrumMaster observes a system of work, make it transparent and identify improvements.
Dont push Agile to people. Dont push practices. Invite people to apply them.
You are 2 minutes late to the daily standup!
No, no, no. This is not The Platz! Do not care about late comers. The team should take care.ScrumMaster is a facilitator, moderator of the discussions. Do not push practices by the books. Identify how they can help the team. Invite people to experiment with the practice for few days, or few times. Sit down with them andanalyze results.
Let people decide what they want to use. Sometimes, they will need time to grow. Or time to realize that Hey Houston, we have a problem.
4. WHO, WHAT, WHEN, WHERE, HOW
You do nothing about that. Literally nothing. It is about a customer, product owner, and team. You help them with the system.
It is very common for ScrumMasters:
- To assign tasks. Instead of team members.
- To write user stories in the backlog. Instead of the product owner.
- To plan sprint backlog ahead. Instead of the product owner.
- To estimate. Instead of team members.
- To updateKanban board. Instead of team members.
- To calculate burndown charts. Instead of tools.
- To feel responsible for all the problems. Instead of invite management to help with problems as well.
- To choose & configure scrum project management tool. Instead of decision done by product owners, agile teams and management as well. Plus ScurmMasters of course.
- To decide what is and what is not an impediment. Instead of the team.
- To calculate the capacity of team members. Instead of team members or the tool.
5. DEFINES AGREEMENTS & STANDARDS
You are equal to other team members. You co-create standards, but do not own them. Indicate misbehaving, help improve the standards.
Here are our rules and agreements we have to follow.
They are prepared based on my ScrumMastership expertise and examples of other teams and organizations.
Booooooooooooooooooooom. Please get out of the building first, take a breath and think what you have done!
Will rules of other teams work in your team? Do they target the same problems and teams goals? Do you know a context of the organizations you are taking rules from? Maybe yes. Maybe most of them. But what if this is just your opinion? What if most of the people see something else, something more important?
Ask teamhow their work life should look like if everything is fine.What kind of values they have. How big overlap of personal values is on the team. How you as a team want to work. I mean the way and principles of work. Ask management what is the minimum. Ask other teams in the company about their standards.Just inspire yourself.
6. DEFINES REQUIREMENTS OR TASKS
ScrumMaster is here to help product owner and the team. But all of them should do their homework.
Product owner didnt have time to prepare requirements up front. She didnt have time to talk to stakeholders or customers what is the next most important user story in the product backlog. No time for the product backlog grooming. Missing acceptance criteria. User stories are just titles.
And here are you, wanna be great ScrumMaster! You do not want to upset the team. You want to help them. Help the team and the product owner. So, you are going to write user stories. You are going to add acceptance criteria. Because you want tohelp all of them soooooo muuuuuch.
Now you failed miserably and will repeat this fail till end of your ScrumMasters life.
You just teach people that there is somebody who will do their job. Without any pain in the ass.
Homework is homework!There are different perspectives when you write requirements that need to be considered. You are probably not aware of them if you do not do that job for 100%.
Let people fail! Do not be afraid. There are always two possibilities. Things can change, or change!
7. DEFINES PRIORITY & PLANS
Do not be a proxy of the product owner. Dot.
ScrumMasters often prepare a plan with the product owner ahead of the team. They prepare the next release, the next sprint. Very often product owners think their job is done in the planning session with the ScrumMaster. But it is not!
The product owner must come to sprint planning with the team as well.
She learns there are some technical blockers that might change priorities of user stories in the sprint backlog. There will be even changes based on unfinished user stories from the previous sprint. You will have to clone, split or move user stories.
There are business drivers behind such changes. ScrumMaster cant decide about them, she is not here due to business priorities.ScrumMaster just helps the team to realize them.
Only the product owner owns product roadmap, milestones, backlog and plans.
8. DEFINES METRICS
Let the team identify goals and impediments. Help them realize how to improve and how to measure improvements.
We have tomeasure progress with burndown Chart.
We have to measure our velocity. We have to measure lead time.
We have to measure a number of defects. We have to measure capacity.
Why are you so sure? Because of Agile? Read the first paragraph, please! Think about KPI. Think about targets you want to achieve. Only then think about metrics you want to define.
No, it is not just ScrumMaster or ScrumMasters Community of Practice. Inviterepresentants of all roles for such discussion.
Of course, you have a lot of tips for agile metrics available already. And, very probably, you will even apply as they are used by thousands of agile teams in the world. But there will be something else.
For example, your stories are very often described just by a title. Dont you want to make those failures transparent? Measure for example Readiness.
Or Happiness index if your team is struggling and they are afraid to talk about that. Or they just talk I feel bad, but in the heart is not so bad at all.
9. NOT ENOUGH COURAGE
You are a servant leader, shield, mentor. Keep calm!
Stay strong! There are problems coming and you are the first one to face them.ScrumMaster is the first to communicate them with the top management executives.
ScrumMaster is the first to indicate broken rules and agreements to the team. ScrumMaster is the first to say we are not doing our job..
You have to have courage and respect to make inefficiency transparent.
YOU ARE CHANGE AGENT!
10. MISSING SYSTEM THINKING
Think end to end. Coordinate with other ScrumMasters. Establish community. Improve processes. Coach clients, management, and teams.
It is always about customers who get a value developed by multiple teams. A team of sales, analysts, product owners, DevOps teams, marketing, and executives as well. Do not optimize just your team. That might be done in few weeks.
Search for systemsissues. Sit down with the management and other ScrumMasters. Map business value flow. Measure lead and cycle time in your process. Optimize with root cause analysis.
2 thoughts on “Why Scrum Masters Fail?”
Hey, it would be nice to ask for permission prior to the republishing.
my mistake. but I gave credit in the bottom.
But if you ask, I can pull it down.