10 Scrum Master’s failures

We see Scrum Masters fail quite often when we support Agile teams in their transformations. Based on stories of more than two hundred Scrum Masters, following are 10 Scrum Master’s failures which we think are the top most important for Agile teams and which we see too often to overlook them.

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 achieving their goals!

Scrum Masters too often say „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 or Scrum do not help to achieve these goals, people will be resistant to applying them.

Team members in such teams very often do not want to do Scrum daily standups. Too often they hate sprint planning. Retrospectives? No way. Because very often for them it was just another process regardless all the benefits that Agile or Scrum brought. Some people need time to understand them.

But saying the words Agile, and Scrum too often will not make the problems disappear. Agile, scrum, agile, scrum, agile, scrum….. See that?

Think about:

1. What do you want to achieve?
2. What does the situation look like when everything is done at the end?
3. What might block you from getting there?
4. What do you need to do to get there?
5. How will you know you are there?

I’m quite 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, and fantastic retrospectives. Connect agile practices to the 5 bullets mentioned above.

Managing

You don’t manage people. You help improve the system of work, and a culture of a company, and remove blockers.

Scrum Master is not a job role. Scrum Master title is not a rank.

Scrum Mastership is a badge you have while you are on duty.

As Scrum Master, you are with people to help them do their job. To provide them with what they need ahead before something becomes a problem, blocker. You are there to communicate with the management about the impediments that the team is not able to solve on their own.

A good Scrum Master observes a system of work, makes it transparent and identifies improvements.

Push

Don’t push Agile on people. Don’t 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 latecomers. The team should take care. Scrum Master is a facilitator and 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 a few days, or a few times. Sit down with them and analyze the results.

Let people decide what they want to use. But sometimes, they will need time to grow. Or to better understand „Houston, we have a problem. “

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 quite common for Scrum Masters:

• 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 update the Kanban board. Instead of team members.
• To calculate burndown charts. Instead of tools.
• To feel responsible for all the problems. Instead of inviting management to help with problems as well.
• To choose & configure the scrum project management tool. Instead of decisions made by product owners, agile teams and management as well. Plus Scrum Masters 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.

Defines agreements and standards

You are equal to other team members. You co-create standards, but do not own them. Indicate misbehaving and help improve the standards.

Here are the rules and agreements we have to follow. I have prepared them based on my Scrum Mastership expertise and examples of other teams and organizations.

Please leave the company first, take a breath and think about what you have done right now!

Will the rules of other teams work in your team? Do they target the same problems and team goals? Do you know the 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 people see something else, something more important?

Ask the team what their work life should look like if everything is fine. 

What kind of values do they have? How big overlap of personal values is on the team. How do you as a team want to work? I mean the way and principles of work. Ask the management what the minimum is. Ask other teams in the company about their standards. Just inspire.

Defines requirements or tasks

Scrum Master is here to help the Product Owner and the team. But all of them should do their homework.

The product owner didn’t have time to prepare requirements upfront. She didn’t have time to talk to stakeholders or customers about 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 you are, want to be a great Scrum Master! You do not want the team to be upset. You want to help all of them. The team and the product owner. So, you will write user stories. You are going to add acceptance criteria. Because you want to help all of them so much.

Now you failed miserably, and you will repeat this fail till the end of your Scrum Master’s 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 100%.

Let people fail! Do not be afraid. There are always two possibilities. Things can change, or change!

Defines priority and plans

Do not be a proxy of the product owner. Dot.

Scrum Masters 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 Scrum Master. But it is not!

The Product Owner must come to sprint planning with the team as well.

She will learn there are some technical blockers that might change the 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. Scrum Master can’t decide about them, she is not here due to business priorities. Scrum Master just helps the team to realize them.

Only the Product Owner owns a product roadmap, milestones, backlog and plans.

Defines metrics

We have to measure progress with burndown chart. We have to measure 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! Understand your problems and goals. Think about KPI. Think about targets you want to achieve. Only then think about the metrics you want to define.

Let the team identify goals and impediments. Help them realize how to improve and how to measure improvements.

No, it is not just Scrum Master or Scrum Masters Community of Practice. Invite representatives of all roles for such a 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 described by just titles very often. Don’t 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.

Not enough courage

You are a servant leader, shield, and mentor. Keep calm!

Stay strong! There are problems coming and you are the first to face them. Scrum Master is the first to communicate them with the top management executives, the first to indicate broken rules and agreements to the team, and the first to say: „We are not doing our job…“

You have to have courage and respect to make inefficiency transparent. Scrum Master is change agent!

Missing System Thinking

Think end to end. Coordinate with other Scrum Masters. 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 a few weeks.

Search for system issues. Sit down with the management and other Scrum Masters. Map business value flow. Measure lead and cycle time in your process. Optimize with root cause analysis.

Make everything transparent. Prepare proofs of failure and invite for discussion. Do Kaizen! Slowly but constantly. As water.