Can We Save the Scrum Master Role Before It Becomes Extinct?

It’s not too late. Here are my answers to 21 burning Scrum Master questions.

Imagine you are a Scrum Master today, struggling to find relevance. You watch in horror as your role loses ground in the market. What questions would you want answered to help you show your value and survive in this tough climate?

Saving the Scrum Master role was the topic of a recent talk I had at a Scrum Masters of the Universe Meetup. The talk centered around my recent article, How Do Scrum Masters Rethink Their Role On a Team to Avoid Extinction? We had an engaging discussion.

The attendees had tons of questions.

To my delight, answering these questions seemed to renew energy and provide a path forward. Let’s face it, many Scrum Masters are struggling to stay afloat in today’s treacherous waters. They feel threatened. So these answers served as a form of a life raft.

But the answers could only reach those in attendance. So, I have compiled the questions and answers here for all to see.

My Answers to 21 Big Questions I’ve Heard From Scrum Masters Who Want to Level Up Their Craft

Many times, a question is an obstacle in disguise.

Most of the questions you find below Scrum Masters have asked many times before. They are common obstacles. Answering them can help many.

I’ve given my experience-based advice in the answers that follow. I’m not claiming these are the only responses or the best, but I’ve found they’ve served me well in my context. Find the questions that speak to you, and see if my answers provide you with a perspective that helps (in your context).

Ready? Let’s go.

Q1: How do you balance the need for transparency with managing stakeholder expectations?

Keep stakeholders close.

I find involving stakeholders makes it easier to align their expectations with reality. Instead of keeping stakeholders at arms-length, pull them near to the work.

Show them what you are working on (and the problem you are working through). Don’t wait until the Sprint Review. Pull them into the Sprint and get their input.

It’s in the best interests of the stakeholders that we are transparent.

The earlier stakeholders know a problem exists, the better. Early learning is the secret weapon amidst complexity and uncertainty.

Know this: most product work is ripe with issues. But to be transparent with these concerns, we must first forge a bond with our stakeholders.

Keeping stakeholders involved builds trust and allows transparency to flourish.

Q2: How do you handle output-driven organizations that believe velocity demonstrates a team’s value?

In my experience, most organizations are output-focused.

They may talk the talk with outcomes but don’t walk the walk. In these cases, I start by educating on the nature of software product work as uncertain and complex. Then, I show them. I measure existing team output versus outcome to give them the stark reality. Outputs don’t guarantee outcomes.

This usually opens their eyes to the truth.

Then, we talk about the difference between busy and focused work.\

An effective team does not look busy, producing ever-higher throughput. Rather, it looks focused and determined to know its users and to delight them.

Powerful teams produce _less _to solve user needs in the time they need solving. All the things we can imagine upfront are often not needed. Instead, we need to learn and emerge the right solution (and no more) through evidence. This is how we reduce our output while maximizing our outcome.

Focus on what’s essential. Show that more of the wrong things faster won’t ever be right.

And velocity will lose its luster.

Q3: What is the biggest mistake Scrum Masters make when trying to master the craft of Scrum?

A lack of courage inflicts much damage.

It holds you back. It holds your team back.

Your customers suffer. Your organization suffers.

And in turn, you suffer, dear Scrum Master.

Not being bold enough to question and change the system of work is a big mistake (in my experience, the biggest).

Courage follows your perceived safety. Low safety, low courage.

I recommend small steps of courage to battle back against the broken system.

Small steps build confidence and prove the value of change to those in power. And I’ve used a great framework for this. Try out the Improvement Kata (from Mike Rother’s Toyota Kata). It helps you and your team turn many small improvements over time into big changes.

A poor system of work is a barrier, and teams must face it and break through it to reveal their potential. Scrum Masters need to lead the way here.

Obstacles are the way to your team’s greatest potential. Have the courage to face them and dismantle them, one step at a time.

Q4: What do you look for in a mentor?

I look for someone who challenges me.

I don’t want someone to compliment me all the time that I am doing a great job. They need to get me outside my comfort zone. I don’t need them to be kind.

Also, I want someone who has done the thing a lot. I want an expert. If I can latch onto an expert, I will accelerate my growth and learning. I want access to someone who has refined the technique many times in many contexts.

To sum it up, I want an expert who’s not nice.

Q5: How do you get supervisors to assess your performance on value instead of the activities you do?

I add outcome measures.

First, I give them what they’re asking for and measure activities and output (yuck). But then, I add the measures for outcome to illustrate how more output does not mean more outcome.

When you start showing the outcome, it makes folks question the output quality. Like magic, they stop focusing on the output quantity. You want to focus on what is essential and obsess over the quality of it. This requires you to know your users and interact with them. Following a recipe and building to upfront specifications won’t get you to value.

You have to show them a better way to measure.

Q6: What are ways to get the powers that be on board and support the move to agility?

Start small. Show results. Gain momentum.

I recommend you perform a small, bounded experiment in a new way of working towards a better state. Then, show the upgrade in results to gain support.

1. Define the future desired state and current state.
2. Create a small, bounded experiment toward the future.
3. Define the expected results of the experiment.
4. Perform the experiment.
5. Measure the results.
6. Show the results to the powers that be.
7. Repeat 2-6 to progress and iterate to the future state.

If possible, involve those in power in every step of the journey. Before long, they will want this happening on every team.

You can’t think your way to a new mindset. Action is what gets you there.

A new mindset follows new, stronger results from new actions.

Q7: What is the role of the organizational system in a Scrum Master’s ability to provide value?

Nobody comes in to do a bad job.

Your system dictates (hinders or propels) your results. Its design is perfect for the results it currently gives.

And changing a system is never easy. The system is self-sustaining. Any attempt to change it is often met with resistance. And this makes it difficult for Scrum Masters to enact change.

Are you hitting walls trying to change the system? If so, you must ask for help. A mentor can help if they have political capital to influence change. Your manager can help. Even a peer who knows some tricks can help.

By facilitating even a small change, you can build proof of value.

Small wins become evidence to yourself and to others that change is good. They build your confidence and other’s confidence in you as a change agent. To show the impact of a change, I use lean wastes to contrast the starting pain and the reduction of it after the change.

Smaller steps not only help you, but they help others change too. Could you create a movement? You bet you can.

Small steps prove your value, inch by inch.

Q8: Who is questioning the value of the Scrum Master and why?

Managers and teams both question the value of the Scrum Master.

More and more teams are being managed by team leads.

Since remote work started, I’ve seen teams retreat to solo work (individuals working alone). Team leads have stepped in to manage them and assign work. Scrum Masters aren’t allowed inside this inner circle. Separate meetings happen in secret without the Scrum Master.

The Scrum Master is becoming a team outcast.

And management now questions why they need a Scrum Master.

Most organizations have never understood the value the role can bring in the first place. And today’s absence of a Scrum Master foothold in the team amplifies the problem. Management has lost enthusiasm and support for the role. They ask, “If team leads are running the team, what’s left for a Scrum Master to do?”

It’s this perfect storm that’s sinking Scrum Masters.

Q9: How do we get managers to see Scrum Masters as valuable change agents?

Let’s face it, Scrum Masters don’t have a voice today to be a change agent.

They need an advocate for them.

Scrum Masters need to find someone in the organization who “gets the joke” on how Scrum Masters add value. This person can help work through the misconceptions higher-ups have about the role. And they can help the Scrum Master make the case for shaping a different belief about Scrum Masters. One that influences changes that enable a smooth flow of value to flourish.

Here’s some good news for you.

Most organizations have mountains of waste impeding a team’s flow. This is a regrettable tragedy. But it’s also a perfect canvas for Scrum Masters who need to paint the case for their worth.

After all, if not the Scrum Master, who will improve flow? Who else is looking out for waste and how to remove it? Nobody.

Got waste? You need a Scrum Master. It’s an easy case to make.

Q10: What if IT management makes Scrum Masters also take on Business Analyst and Project Manager work?

I’ve seen this play out.

You get asked to do real work and do this Scrum Master stuff on the side. It’s clear those asking this don’t see value in the role.

Adding these other tasks to your plate ensures the Scrum Master ones will die. They won’t have any space to thrive.

How do you prove this is a problem? Again, use the waste as your friend. You can say, “I can do these other jobs, but who’s going to be looking out for and removing all this waste?” That should kick-start the conversation back into the right focus. And it helps you make the case for the importance of Scrum Master responsibilities.

If you split your time juggling many hats, something will suffer.

Don’t let value flow be the thing to suffer.

Q11: How have you successfully modeled self-organizing behavior in your teams?

You can’t model self-organization if you aren’t around.

And you can’t teach it by delivering a presentation on it.

You model self-organizing behavior one way. By being with the team, rolling up your sleeves, and solving problems with them.

Be aware that we have a drought of self-organization in teams today. You may ask your team, “What do you think we should do about this?” And then they stare back at you and say nothing. They likely have never had the agency to “think” like this, have an opinion, or make recommendations.

So you say, “Here’s what I would do.” Explain your perspective. Then, you say, “What do you think about that?”

Often, this makes it safer for them to contribute because you took the first step. And once they, open up and start giving their viewpoint, you’ve broken the logjam. From here, they can start to build their voice.

A team new to self-organizing behavior is like a new swimmer clutching onto the side of the pool. They don’t want to drown. You are the swim coach helping them learn the moves so they gain courage to let go of the wall and swim on their own.

Solve with them. Be present. Roll up your sleeves. Teach them the moves.

Then, get out of the way.

Q12: What strategies do you use to teach self-organization to teams new to Scrum?

One interesting thing about self-organization: it’s easier to do when you work as a team.

Most teams, when they start Scrum, aren’t used to the high degree of collaboration that’s required. Each member is usually accustomed to working solo. More like a collection of individuals than a team.

This is an opportunity for you to teach them teamwork to learn how to self-organize. Move the team from working solo on individual tasks to working together on one thing at a time. The more you can do this, the faster they will build self-organizing behavior.

Collaboration has many benefits for self-organization:

• Builds cross-functional knowledge.
• Builds habits for members to support each other.
• Develops confidence as a team to try new things.
• Builds team ownership and pride around their work.
• Helps the team to finish together with no member left behind.

And If you are right there with them as a Scrum Master, you can coach them as they collaborate. Avoid being a Scrum Master whose only touchpoint with the team is the Daily Scrum. You can’t coach self-organizing capability if you aren’t there in the moment.

When we were in the office, this was easier. Now that we are remote, we have to work harder to make this happen. But with a little ingenuity, it’s possible.

Teamwork and real-time coaching build self-organization chops.

Q13: How do we handle Engineering Managers serving as Scrum Masters to gain control of the team?

This is happening because management desires control.

The desire for control has always been present in software development. Managers want to gain control of this black box and figure out when the work will get done. It’s a persistent quest.

Now that we’re remote, the opacity has gotten worse. And the desire to control has amplified. This is why you see managers as Scrum Masters.

Management has missed the message that you can’t control software development.

It’s not about control. It’s about learning.

• How do we pivot fast?
• How do we harvest early value?
• How do we work small and think big?
• How do we use early evidence to remove risk?

This learning-forward technique doesn’t compute for most managers.

And managers managing teams create order takers, not problem solvers.

We need more people who can think on the ground and solve problems on the terrain. We don’t need someone to tell the team what to do because this assumes we can control things from a central perch. Centralized command and control fails when ground-truth learning is mandatory.

We need decentralized thinking and reasoning. And we must avoid the gut reaction to exert more control.

As change agents, Scrum Masters have to prove that self-management works. They do this by running small experiments and showing the value.

1. Run a sprint where the team decides how to achieve the goal.
2. Measure the results.
3. Iterate in the next sprint and get better.

Here’s a secret tip. Bring the manager along with you for the ride. Have them help build the team’s problem-solving muscle. This gives them ownership in helping the team grow stronger.

Sorry. There are no shortcuts.

You’re going to have to prove control is inferior.

Q14: Are companies only questioning the value of Scrum Masters? Or are they also questioning the value of Agile?

It’s all related, for sure.

And it comes back to the control issue.

Most folks in the C-suite thought that Agile was going to get them more, better, faster, and cheaper. It was an output-oriented perspective. When this didn’t pan out, they decided to reject not only Agile but Scrum and every other Agile-related thing.

They were not getting what they desired out of Agile.

And they had the wrong assumption that control was reasonable. They missed the fundamental learning aspect of product work.

Plus, many organizations didn’t change at all. They added Scrum on top of their wasteful system. When they didn’t get the output utopia they desired, they couldn’t justify the overhead.

So, they ejected Agile and Scrum. And Scrum Masters are part of that package.

They’re throwing out the baby with the bath water.

Q15: How do you spot the early warning signs of problems before they become major blockers?

It comes with practice.

You have to get in the reps of solving problems. This is the only way to understand the common root causes that lead to downstream issues.

Study why problems happen, and identify the signals to watch out for. If you keep doing this, you’ll start seeing the patterns. You’ll develop a form of early detection radar to spot the warning signs.

And once you have done this long enough, you will develop eyes for waste.

Q16: How do you decide when to intervene and when to let the team solve an impediment on their own?

Letting the team decide is crucial, but remember you are part of the team.

If your team has a handle on the problem and is all over it, leave them to it. Jump in and solve it with them. Be part of the team.

But let’s say your team does not see the impediment as a concern. And you know from experience that the risk is high of a downstream problem if you don’t remove the impediment.

You should describe the problem and how you have solved it in the past. And outline the risk to them and the product if they don’t address it. Ask them what they think. They may still ignore it. And you must still let them decide.

But now you have put the team in a better situation.

Because now, no matter the outcome, you have a win.

• They take your advice and avoid the problem. Win.
• They don’t take your advice and they get lucky. Win.
• They don’t take your advice, hit problems, and learn from it. Win.

Always let the team decide, and make sure your voice is part of the decision.

Q17: How do you remove blockers when they are flying at you from all directions?

Calm down and find a focus where you can make a difference.

If you have many things blocking you, you have to destress the situation, so you can gain back sanity. I do this by mapping obstacles to a pain-control matrix.

If you have high pain within your control to remove, you should focus there first. Remove one obstacle in this category. And keep removing high-pain, high-control blockers one by one until you have none left.

If you have high-pain blockers you can’t control, pick one and then ask for help. Once removed, ask for help from the next one. Repeat until all these go away.

This is what I call my pain-control matrix for blocker obliteration. It helps me gain momentum over the high-pain problems within my control. And gather support for those I can’t.

Do this and, before long, your team’s flow will be smooth and steady.

Q18: How do you handle situations when many team members do many things at once?

This is simple.

Do fewer things. This is how you focus.

Do them at a sustainable pace. This is how you survive.

Do them with an obsession for quality. This is how you build things right.

It’s simple, right? Yes, but not always easy.

Easy should not be an assumed state in our product work, though.

Doing fewer things at a sustainable pace with quality is a goal worth pursuing. It results in smiling customers who get what they want sooner. It produces thrilled stakeholders counting their cash. And it creates fulfilled teams who love their work.

A focused, steady, quality effort makes for a win-win-win scenario.

Q19: How do you handle when team members are not paying attention on calls? They multitask and don’t pay attention.

I’ve experienced this situation often when teams are remote.

When I’ve encountered this, I usually perform a team chartering activity.

Chartering is great for team building. But one thing of note in a solid chartering activity is something called team norms. You ask the team how they would like to show up for each other.

Sometimes, the notion of not multitasking during calls comes up. But sometimes, it doesn’t. Don’t hesitate to mention it yourself. They may or may not agree to it, though.

That’s fine. Continue to check in on the norms during the Sprint Retrospective. Keep discussing it as a concern and how it affects the team.

In time, most teams will come around and suggest a new norm. For example, I’ve seen some teams propose a norm to turn their cameras on during Sprint Events. It’s harder not to pay attention when you are on camera.

Give team norms a try, and see if it helps.

Q20: How do you handle situations where teams don’t task out and plan their work?

This is only an issue if team members work solo.

When I go into teams I immediately sense a problem if everyone works alone. Everyone has their own story and their own task. This is not teamwork.

But if they work together on one thing at a time as a team, they move as one all day long. Everyone knows what everyone else is doing because they are working together. No need to task everything out in detail.

When a team does work together, tasking is no longer a concern.

Q21: How do we help more junior team members get a chance to work with more senior (experienced) team members?

Collaboration is key.

A big part of the Scrum Master’s role is to help the team set a goal and work collaboratively to get there.

Collaboration means all team members, junior or senior, work together on one thing at a time. This elevates the game of the team.

When teams collaborate, you finally experience the true value of teamwork. You experience the whole being greater than the sum of the parts.

This collaborative focus helps junior folks grow their craft. They learn by working with experienced leads on the same thing at the same time in the same place.

To be a professional team, in my experience, you have to work together.

---

That’s it. I hope these answers help you in your journey to make Scrum Masters relevant and valuable.

Don’t give up.

We can save the Scrum Master from extinction together.

➡️ Sign up for weekly insights like this on getting back to the fundamentals that underpin unstoppable product teams.