Winning Strategy: Career Track

From Servant Leader to an Agile Delivery Lead

Vibhor Chandel — Thu, 15 Jan 2026 14:10:02 GMT

This is a continuation of last week’s post.

If you haven’t already, check it out at the link below:

The new job market is mostly looking for Agile Delivery Leads and fewer Scrum Masters. Moving from Scrum Master to Agile Delivery Lead is not a promotion that involves “more authority,” though.

It’s a change of beliefs… again!

In the past, we moved from Authoritative Project Managers to Servant Leader Scrum Masters.

We learned about Agility
We learned about reducing waste, etc.

The time has moved again, and now, in this new AI age, we need to move from being a Servant Leader who watched everything from the outside, without accountability, to being an Agile Delivery Lead who has skin in the game.

As a Servant Leader, your primary view was:

“How do I help the team succeed within the Scrum system and remove impediments?”

As a Delivery Lead, your view becomes:

“How do we reliably deliver outcomes, manage risk, and build trust across the delivery ecosystem… while still protecting agility?”

Let me be clear here, though.

As an Agile Delivery Lead, you do not abandon servant leadership.

No!

You are expanding it into a broader, outcome-focused partnership with Product, Engineering, and most importantly… the Business.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

My Advice for Scrum Masters to Get a New Role Faster

Vibhor Chandel — Sun, 11 Jan 2026 14:08:25 GMT

You must understand (if you don’t already) that the market for Scrum Masters has changed.

That’s the simplest way to put it.

You won’t get hired solely on the basis of a two-day certification and a theoretical understanding of the Scrum Guide. Those days are FAR gone.

Today, organizations are looking for value delivery, change management, and pragmatism.

So if I were looking for a role right now, I wouldn't just apply… I would follow a strategic plan.

Below are the steps I would use to land a new role faster… specifically in today’s market.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

As a Scrum Master, how do I make sure my impact is seen, heard, and valued?

Vibhor Chandel — Sun, 30 Nov 2025 14:04:51 GMT

“So what do you actually... do?”

I’ve lost count of how many times I’ve been asked this question as a Scrum Master in my beginner years. Usually at dinner parties. Sometimes in meetings.

And I get it.

As a Scrum Master, you don’t write code. You don’t design features.

But that doesn’t mean you don’t make any impact.

Your impact is real.

The problem is that you’ve heard people saying, “Great Scrum Masters are invisible.”

That’s the line I kept hearing in my beginning years.

I stayed quiet, working in the background, and watched the team get all the credit.

Then, once my VP pulled me aside and asked:

“Remind me again what exactly you do here?”

It hurts when someone asks you that.

Invisible impact doesn’t get you promoted. It doesn’t get you recognized.

Invisible work is the easiest work to ignore, especially in organizations that think “value” is whatever shows up in a dashboard.

In this post, I’ll share the simple strategies I have used and later taught many teams to make sure stakeholders see, hear, and value what you do as a Scrum Master.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read this before starting with a new team as a Scrum Master

Vibhor Chandel — Thu, 31 Jul 2025 13:06:27 GMT

Welcome to the 🔥 free edition 🔥 of Winning Strategy: A newsletter focused on enhancing product, process, team, and career performance. If you’d like to become a paid member, please see the benefits here, and feel free to use this expense template to request approval from your manager.

Q: My worry is that I am starting a new job as a senior Scrum Master in one of the biggest energy sectors in Germany, after being out of the field for almost a year plus I will cherish if you can give me good solid points on what to do most and what to watch out for in simple steps and point form, (take note I have read your 30,60,90 day plan and got a plan however it will be nice for you to pin point major issues which from ur opinion I should not forget?)

Thank you for the question.

Side note: This question was asked in the subscriber’s chat, and I wanted to answer it in a newsletter post because I believe it can help many people in similar situations, some of whom I know personally.

Although the post is directed at helping the asker with their particular case, the underlying fundamentals and ideas apply to any role, whether starting with a new team, job, or company.

If you are also a Scrum Master, or if you are a Product Owner or an Agile Coach, you can create a 90-day plan using the information in the posts below:

I wrote these posts based on my personal experiences and those of others who initially faced struggles, learned from their mistakes, and ultimately succeeded.

In today's post, I want to help the asker with his concern (worry) and share some personal insights that can boost his confidence in his new venture.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

#1 Be confident

You mentioned in your question that you've been between jobs for a long time. This is becoming more common than you think, and it's perfectly okay. What matters is not the gap, but how you approach your return.

The fact is: THEY HIRED YOU!

The company saw your potential and capabilities. They chose you among other candidates because they believed in your ability to deliver value as a senior Scrum Master.

You're returning with Fresh eyes to see things objectively.

One of the biggest energy sectors in Germany means:

They have processes in place
They deal with complexities in projects
They need experience to handle scale

They saw these qualities in you.

Your worry about the gap shows you are committed. You want to succeed.

I would channel this energy into curiosity rather than concern. Use this energy to do 3 things:

ask questions
understand the team’s contexts (background, systems) and
build relationships

When you know what you are doing, you are not merely confident.

You FEEL it in your bones.

#2 Get introduced

With the mindset of Step #1, do the following next.

Ask your Hiring Manager to introduce you to the team. This is where your team will make their first impression of you.

First impressions stick.

You can pre-brief your manager on:

what to say: why you were hired (credentials, experience, etc.), what problems you’ll help solve (expectations)
what not to say: “Ben will fix the team.”

Also, prepare a 20-second self intro. Something like:

“Hi, I’m Ben. I will be a part of this team. My focus will be on making it easier for us to deliver value. For the first couple of weeks, you’ll mostly see me listening (observing) and asking questions so I can gather enough information about what we are doing. Looking forward to learning from you all.”

Smile, then stop talking. Invite them in.

I highly recommend checking out the Scrum Master Engagement Funnel to prepare your team for receiving your help.

#3 Learn about their expectations

You got yourself introduced. They know:

what you are capable of
what is your goal within the team (making it easier for the team to deliver value)

Now it is time to know what they (Manager, Team members) “expect” from you.

Remember: Expectations of your manager and your team always take priority.

To learn more about:

Why expectations
Whose expectations
How to find Manager’s expectations
How to find team’s expectations

Check out the post I wrote last year How a Scrum Master Handles New vs Mature Teams?

The post outlines all the steps (with detailed examples) you need to take and the questions you must ask to create a personalized roadmap that you can work from.

#4 Find out your team’s current state and process

You know what they want from you. You know their expectations. You are excited to get started.

But where to start? What will be your first action?

To help your team achieve their goals, you need to understand its current situation.

Where they are… right now?

You can find this information in 2 steps:

Detailed steps on how to do these are in the above-linked posts.

To learn about the gaps in their current process, check out the post below:

When a Scrum Master joins a new team how do they check the process?

#5 Draw a stakeholder map

You know your team‘s current state. Now you need to understand why they are where they are. Who’s driving your team?

In short, you must identify the stakeholders. These include but not limited to:

Primary Stakeholders:

Your direct team members
Product Owner (Product Manager)
Immediate management
End users of your team's deliverables
Adjacent technical teams

Secondary Stakeholders:

Sponsors
Department heads involved
Compliance teams involved
Security teams involved
External vendors involved

Important: Don't just list names and roles. Understand (1) their level of influence on the team, (2) their interest in the team's success, (3) their communication preferences, (4) their pain points and priorities.

Check out the posts below to make a list with all the details:

A mistake I often see people make is assuming stakeholder relationships based only on the organizational chart.

Do look at the chart. But then sit down with your manager to connect the dots and learn more about them.

#6 Understand the product

You know “what” the stakeholders want from your team. Now it is time to understand “how” your team is delivering it.

This is where understanding The Product comes in.

Stakeholders’ want = Problem

How your team delivers it = Solution

To learn how to go about understanding the “Product,” check out the post below:

How to Understand The Product As A Scrum Master?

This post outlines the steps to help you create a simple Process Map that you can use to understand exactly how your team is solving the stakeholder’s “Problem” and delivering the “Solution.”

#7 Find your champion

This is someone who has an influence on your team. Usually, this is the Product Owner or Product Manager.

It is essential to establish a good working relationship with them from the outset.

To understand the types of Product Owners, check out the post below:

Why some Product Owners are Harder to Work With than Others?

Once you have pinpointed the type of your PO, set up your first 1:1 meeting with them.

Note: You can use this 1:1 to replace your 1:1 with the PO in Step #4 (find out your team’s current state) above.

Check out the post below to learn more about what questions to ask in this crucial 1:1 with your PO:

30 Questions to ask a Product Owner

This step will help you make an ally who will support your team or process-related suggestions.

The Journey Forward

Each of the above steps builds momentum for the next:

Confidence (#1) will help you make an effective introductions (#2)
A good first impression through introductions will allow you to uncover expectations (#3)
Understanding expectations will lead to assessing the team’s current state (#4)
Knowing the team’s current state will help you in identifying stakeholders (#5).
Knowledge about the stakeholders will give you the context to understand the product (#6) and how your team delivers value
And finally, knowing who the team listens to (#7) will help you in making improvement suggestions

These are the 7 things I believe are most important and must be done within the first 30 to 45 days of joining a new team as a Scrum Master.

There is a lot more that accompanies these steps, which you can learn using the links below:

Having said that, there are also a few NOT-to-DOs you should keep in mind. You can check them out at the link below. I wrote them specifically for Agile Coaches, but they also apply to Scrum Masters.

10 Mistakes In Your First 30 Days

With that, I wish you all the best for your new beginnings.

Show your support

Every post on Winning Strategy takes ~ 3 days of research and 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly recommend that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Available for iOS and Android

Connect With Me

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America's largest banks.

11 Rules of Thumb for When and How to Escalate Any Issue at Work

Vibhor Chandel — Thu, 03 Jul 2025 07:15:13 GMT

Escalation is a double-edged sword for Scrum Masters.

Handle it well, and you protect the team and the project. Handle it poorly, like escalating too soon, too late, or to the wrong person, and it could cost you your credibility, or worse, your job.

I recall standing outside a meeting room after a particularly heated sprint review, debating whether to email the department head about a stakeholder who was consistently derailing team confidence.

The question kept echoing in my mind: "Is this the right thing to do? Should I escalate?"

If you're a Scrum Master, you've probably been there too.

So, when do you escalate?

And how do you do it without crossing boundaries?

Escalation is sometimes necessary, but it must always be done with care, clarity, and a sense of the organization's culture.

Over the years, after coaching teams in various sectors, including start-ups, banks, and government IT, I’ve developed 11 rules of thumb for when and how to escalate issues so you not only protect your team but also protect yourself.

In this post, you will learn:

When to escalate (and when to hold back)
How to protect both your team and your role
Who to approach first (and who to avoid)
What alternatives exist before escalation

Let's get started.

If you’re new, here’s what you missed

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

#1 Tie the issue to a Business Risk first

Before you even think about escalating, ask yourself: Can I tie this problem to a real business risk?

Here’s a rule of thumb:

If you can’t complete the sentence, “Because of X, we may miss Y (deadline, revenue, compliance, morale),” then the issue you’re dealing with isn’t an escalation item. It’s just a nuisance.

I’ve seen Scrum Masters escalating every impediment, big or small.

It’s tempting, especially when you care about your team. But without a clear business risk, your escalation will sound like noise, not a signal. Worse, you risk being seen as someone who overreacts.

The test is simple:

Ask yourself, “What’s at stake for the business if this continues?”

If the answer is vague or unconvincing, pause for a moment. Go back and clarify the impact before you raise any flags.

Escalation is about protecting outcomes, not just fixing annoyances.

When you tie every issue you escalate to a real business risk, you speak the language that leadership cares about.

#2 Exhaust team level options before going up

Escalation should never be your first course of action.

Before you even think about reaching outside the team, pause and ask yourself:

"Have I tried facilitation, data transparency, experiments, and education inside the Scrum Team?"

If the answer is no, it’s not time to escalate. Stay local.

In my early days as a Scrum Master, I once flagged a recurring blocker to management before even discussing it with the team. The result? The team felt blindsided and lost trust in me.

I learned the hard way: Most issues can and should be solved at the team level first.

Facilitate a tough conversation
Make the problem visible with data
Run a small experiment
Share knowledge or clarify roles

If you haven’t worked through these options, you’re skipping the most critical step: Empowering your Team.

Escalation is for what the team can’t resolve, not what it hasn’t tried to resolve.

#3 Do a written, time boxed agreement

One of the quickest ways to lose credibility during escalation is to lack evidence. Before you escalate someone’s broken promise or unfulfilled commitment, make sure you can prove that the promise existed in the first place.

A simple, two-line email is enough.

For example:

“The API team will provide the authentication endpoint by next Thursday.”

That’s it.

It sets expectations and provides everyone with a clear reference point.

The best escalations are the ones you never have to make because expectations were clear from the start.

#4 Look for multiple occurrences, not one-offs

Not every problem is worth escalating, especially if it’s a one-time issue.

Escalation becomes far more credible and impactful when you can show a pattern of repeated behaviour or a systemic weakness.

Here’s a simple rule of thumb:

First occurrence → Coach with curiosity
Second occurrence → Coach with clarity
Third occurrence → Now we're talking escalation

Let me share an example. I once dealt with a Product Owner who kept changing sprint priorities mid-sprint:

Sprint 1: Changed priorities once → Had a friendly coffee chat about sprint commitment
Sprint 2: Changed again → Scheduled a focused workshop on agile principles
Sprint 3: Same behaviour → Now we had a pattern worthy of escalation

Why this "rule of three"?

Because patterns reveal either:

Intentional disregard for agreed-upon processes
Systemic problems in the organization
Cultural misalignment that needs leadership attention

These are exactly the things leaders are paid to address.

Show your support

Every post on Winning Strategy takes ~ 3 days of research and 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly recommend that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Available for iOS and Android

#5 Collect 2 metrics, not 20

When you’re preparing to escalate, don’t show up with a spreadsheet full of problematic metrics.

Pick two metrics, no more:

One delivery metric (like Sprint Goal met percentage)
One quality metric (like escaped defects)

That’s it.

Leaders don’t have time for a “metric soup.”

They need a clear, focused signal. Trending data on two well-chosen metrics earns attention.

Twenty scattered numbers earn eye-rolls.

Escalation doesn’t require you to prove how much data you can gather. It requires you to present the correct data to drive action.

#6 Escalate with an ally

When it’s time to escalate, don’t go it alone.

Solo escalations risk coming across as personal grievances, regardless of how valid your concerns may be. To avoid this, always bring an ally into the conversation.

This could be:

The Product Owner, who can speak to business priorities
The Tech Lead, who can provide technical context
An Agile Coach, who can offer an unbiased perspective

I’ve seen solo escalations backfire.

It’s too easy for leadership to dismiss it as one person’s opinion (or agenda). But when you walk in with a respected peer by your side, you send a message that says: this isn’t just your problem, it’s the team’s.

Even a quick sync beforehand, “Are we seeing this the same way?” can make all the difference.

Don’t be the lone voice in the hallway. Build a coalition, then speak up.

You’ll be heard.

#7 Offer a solution, not just a complaint

There's an old saying: "Don't bring problems to leadership; bring problems with proposals."

Escalation is about moving things forward.

If you come to leadership with only a problem, you risk sounding like just another complainer. But if you pair the problem with a rough solution, you demonstrate initiative.

Here’s the difference:

Bad: “People keep changing requirements. It’s unproductive for the team.”

Good: “Mid-Sprint priority swaps increased carry-over by 25%. I suggest we limit swaps to Sev-1 incidents only.”

The first is noise. The second is data-driven, specific, and actionable.

In my experience, leaders respond best when you show you’ve thought things through. You’re not just pointing out the fire, you’re handing them a fire extinguisher.

#8 Keep the message ≤ 3 minutes

Executives tune out fast.

Executives are busy, and their attention spans are short. If you can’t deliver your message in under three minutes, you risk losing their focus.

I now live by this formula:

3 slides = 3 minutes = 3 chances to get your message across

Slide 1: Impact Trend

One clear graph
"Team delivery rate dropped 40% since March"
No complex annotations needed

Slide 2: Root Cause

One powerful sentence
"Lack of dedicated UX resource creates rework loops"
That's it. Move on.

Slide 3: Solution & Ask

Proposed experiment
Required support
Expected outcome
Timeline

Example:

Slide 1: Chart showing sprint goal completion dropping from 90% to 45%

Slide 2: "Technical debt from rushed features is causing 60% of our bugs"

Slide 3: "Request: Two-sprint technical cleanup window. Expected outcome: 30% faster delivery by Q4"

That’s it. No rambling, no deep dives, no detours. Just a crisp summary that respects their time and gets straight to the point.

#9 Don’t use Agile jargon

When escalating an issue, avoid using terminology specific to Agile.

Terms like “violating Scrum” or “breaking WIP limits” might resonate with your team, but they won’t land well with leadership. Executives speak the language of cost, time, scope, and risk. And that’s the language you need to use.

Here’s the universal language of business:

Cost (dollars, hours, resources)
Time (delays, deadlines, delivery dates)
Scope (features, functionality, deliverables)
Risk (compliance, market share, customer satisfaction)

Your job isn't to educate leaders on Agile terminology during an escalation. Your job is to communicate business impact and solutions clearly.

#10 Maintain Psychological Safety

Escalation shouldn’t come at the cost of trust.

This means never naming and shaming individual Developers in escalation. If you’re pointing fingers at specific team members, you risk creating a culture of fear and defensiveness.

Focus on the system, not the people.

Don’t say: “Developer X isn’t completing their tasks on time.”

Say: “The team’s work is being delayed due to unclear priorities and frequent context switching.”

The first statement singles out an individual.

The second highlights a systemic issue.

If psychological safety is compromised, collaboration, creativity, and productivity will suffer.

So!

As a rule, always frame escalation around processes, workflows, or systemic challenges.

When in doubt, ask yourself, “Will this message help my team feel supported or attacked?”

Then adjust accordingly.

#11 Escalate up, then let go

Once you’ve escalated, take a step back. Don’t be a helicopter or try to micromanage the result. After leadership addresses the issue, your role shifts from being a driver to a facilitator.

What good letting go looks like:

"I'm available if you need any additional data"
"Let me know how I can help move this forward"
"I trust you'll handle this appropriately"
"Keep me posted on what you need from the team."

What hovering looks like:

"Just checking in on that escalation again"
"Have you made a decision yet?"
"The team is asking me daily about this"
"When will we see action on this?"

Hovering over the process or micromanaging the outcome makes you look political and undermines trust.

Trust the process.

You can also set up regular check-in points instead of constantly following up.

"Would it be helpful to review progress in next month's review?"

Your job is to raise the flag, not to keep waving it.

Once leadership acknowledges the issue, trust them to do their job just as you want them to trust you to do yours.

The Journey Forward

Escalation is a powerful tool, but it must be used thoughtfully.

You can use these 12 rules of thumb as a personal checklist to evaluate every situation before escalating.

Have I exhausted coaching options?
Is this truly an organizational impediment?
Do I have written agreements?
Can I show a pattern?
Are my metrics clear and focused?
Have I enlisted allies?
Is my solution concrete?
Is my message concise?
Have I translated the Agile-speak?
Am I protecting my team?
Am I ready to let go?

Lessons I have learned:

Escalation is a powerful tool, not a first resort
Your credibility is built over the years but can be lost in minutes
Team trust is harder to rebuild
Sometimes the best escalation is the one you don't make

Use them wisely, and they'll serve you well in building credibility and, more importantly, in keeping your job.

Connect With Me

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America's largest banks.

My morning routine that boosts my presence as a team coach

Vibhor Chandel — Sun, 08 Jun 2025 07:15:21 GMT

Hello 👋, It’s Vibhor. Welcome to the 🔥 paid member only🔥 edition of Winning Strategy: A newsletter focused on enhancing product, process, team, and career performance. Many subscribers expense this newsletter to their Learning & Development budget. Here’s an expense template to send to your manager.

For a long time, I believed that PRESENCE was something you either had or you didn't. Like being naturally funny, some people just got lucky in the genetic lottery.

The year was 2012.

I was an Agile Coach, and this (false) belief was costing me dearly.

I would walk into team meetings feeling unprepared. I had done my homework, but I hadn't prepared MYSELF. My mind was still scattered from emails, and my energy was more reactive than intentional.

And it showed!

People around could feel it. I could feel it.

Those were the days when I felt like I was working twice as hard for half the impact.

Until this one day.

I was mentoring a new Scrum Master who seemed to have this natural ability to create instant rapport with his new team. After watching him facilitate a few difficult sessions effortlessly, I had to ask:

"How do you always seem so... present?"

Honesty, I didn’t know what to ask. Which question could help me get the right answer? So I asked whatever came to my mind.

"I don't wing my mornings anymore. I have a system."

His answer surprised me.

Anyway, that conversation led me down a rabbit hole of research about how top performers start their days.

Harvard Business Review found that 92% of highly productive people follow planned morning routines, explaining,

They don't just get ready for work. They get ready to lead.

In this post, I’ll walk you through my morning routine and how it can transform the way you lead.

Let’s get started.

How to speak the language of AI?

Vibhor Chandel — Thu, 15 May 2025 07:15:17 GMT

Let’s say you're in Spain (those who can’t speak Spanish…) and need directions to the nearest café.

You find a person on the street and ask,

“Uh... café? Go... where?”

The person might understand you, but you don’t know Spanish. So, their response (unless they know English) will likely be unclear or frustrating.

Now, let’s say you know just enough Spanish to ask:

“¿Dónde está el café más cercano?”

Suddenly, the conversation flows. You get clear directions …and maybe even a friendly smile.

That's exactly what's happening when most people try to communicate with AI.

They're speaking "human" …to a system that needs specific instructions in a particular way. They're pointing and gesturing with unclear prompts, getting frustrated when the AI doesn't understand…or worse, provide an output that they don’t want.

AI doesn’t magically understand what you mean.

It responds based on how well you "speak its language," i.e. the Prompt.

The better your prompts, the better your results.

In this post, you’ll learn the grammar that the AI understands. You will use this grammar to prompt AI to get your desired output.

Let’s get started.

Get the Substack App (Recommended)

I highly recommend downloading and using the Substack app. This will enable you to read the full newsletter without the length restrictions typically imposed by email clients like Gmail.

Furthermore, you will be promptly notified of the community chat discussions and educational notes I post regularly.

Available for iOS and Android

What is Prompt Engineering?

It is the set of rules and structures that help AI interpret your input.

I watch a lot of sports for fun and relaxation.

Don’t ask me the names of players. I don’t know their names. I just enjoy decoding the secret communication that happens between the players and their coaches.

The players already know how to play the game, but those signals give them specific instructions to make the right moves.

In the same way,

Prompt Engineering adds structure and clarity to your request, helping AI understand exactly what you're asking for.

For example:

Generative AI vs Agentic AI

Vibhor Chandel — Thu, 08 May 2025 07:14:23 GMT

As a Scrum Master, you might be feeling curious about AI and wondering where to begin your journey.

You're not alone.

The Agile world is evolving with AI, and as a Scrum Master, you’re at the forefront of that change. But how will AI shape how Agile teams work, and what does it mean for your role?

Let me tell you upfront: NO ONE has a definite answer.

However!

Many teams have started taking a scientific approach to find the answer.

Last week, I shared the findings of one such experiment conducted at the company I am currently engaged with. If you haven’t yet read that post, here’s the link:

How AI Will Transform The Agile World?

One thing is absolutely clear:

Everyone who is a knowledge worker is currently exploring AI.

This post is the start of our exploration. I am starting with the introduction of the two types of AI technologies you need to know about:

Generative AI
Agentic AI

These technologies will not replace you as a Scrum Master. Let me clarify this at the start. They’ll empower you to work smarter (I know you’ve heard this many times now, but bear with me…)

In this post, I’ll break down:

The difference between Generative AI and Agentic AI
How will these technologies fit into Agile practices
The changes they will bring to your role
The AI tools that are currently being used by Agile teams

This post presents insights and findings based on current events in the AGILE + AI space worldwide. The links to the researched sites are included at the end of the post.

The future of Agile is full of possibilities.

Let’s take the first step together.

What is Generative AI?

You’ve probably heard the buzz around Chatgpt, Gemini, and other Generative AI tools. But what exactly is Generative AI?

Generative AI is a type of AI that “creates content” based on prompts.

Content such as:

text
images/videos/audio
code

The key characteristic that defines Generative AI is that it's REACTIVE.

It waits for you to ask something. Only then does it generate a response.

Emphasis on “Only then…”

It's a super-smart assistant that can write, analyze, and create, but only when specifically asked to do so.

It lacks initiative.

Mistakes I Didn't Know I Was Making As a Growing Scrum Master

Vibhor Chandel — Thu, 24 Apr 2025 07:15:28 GMT

“The worst Scrum Master is the one who doesn't know they're making mistakes."

These are my words that I wrote for myself!

I wrote them in my journal after a particularly humbling retrospective where my entire approach to Scrum Mastery was questioned.

Not by others; I could have handled that easily.

By myself!

You see, I had fallen into the classic trap: I was doing everything "right" according to the textbook, yet something was clearly wrong.

My teams were going through the motions. Events were happening on schedule. User stories were being completed. Everything looked perfect on paper.

But impact? Real, meaningful impact?

The one that comes with professional growth?

That was missing!

I was making mistakes that weren't showing up in any metrics or KPIs. Mistakes that were invisible to daily standups or sprint reviews. Mistakes that were subtly undermining my effectiveness as a professional.

In this post, I'll share:

Those mistakes that taught me some valuable lessons
How I identified those mistakes (sometimes the hard way)
The specific actions I took to correct them
The outcomes that followed

Let’s get started.

Mistake #1: Not Reaching Out to Executives

I kept my head down, thinking leadership exposure was unnecessary.

Big mistake!

How I Realized it?

In the beginning, I focused exclusively on my team. I believed my job as a Scrum Master was to facilitate their success… nothing more.

Then, during a leadership Q&A, an executive asked me this simple question:

“How does the team’s work align with our strategic goals?”

I froze. (there was no Product Owner in my team.)

I stumbled through an answer. But deep down, I knew I had no real connection with executives. I didn’t understand their vision. And worse? I wasn’t helping my team understand it either.

What Was Holding Me Back

I told myself it wasn’t my job to engage with executives. I convinced myself it was “outside the scope” of my role.

In reality?

I was intimidated.

Reaching out to leadership felt like stepping into a completely different world, one where I didn’t belong.

How I Fixed It

The fix wasn't comfortable, but it was necessary.

I started scheduling 1:1 conversations with executives and stakeholders.

At first, it felt like I was breaking some unwritten rule. Like a junior developer trying to schedule time with the CTO.

But you know what?

They accepted.

Not only did they accept, but they were also eager to share their vision, their challenges, and their priorities.

Outcome

These conversations changed everything.

Suddenly, I could see the bigger picture. I understood why certain initiatives were prioritized. I could connect my team's daily work to organizational objectives.

I became a bridge between the tactical and the strategic. Between the daily stand-ups and the quarterly objectives. Between the team's challenges and the organization's vision.

My role evolved from "that person who facilitates Scrum events" to "that person who helps us align and deliver real value."

And my team?

They started seeing their work differently, too.

Not just as items in a sprint backlog, but as important pieces of a larger organizational puzzle.

From me to you

If you're keeping your head down, thinking executive engagement isn't part of your role...

Stop. Look up. Reach out.

Because sometimes, the most significant growth happens outside your comfort zone.

And trust me, those executives?

They want to hear from you more than you think.

Mistake #2: Focusing Only on Coaching

I was so focused on coaching that I forgot something important: sometimes, people need to be taught.

How I Realized the Mistake?

It happened during a sprint.

A developer came to me, confused about velocity.

"We're still not really sure how velocity works."

My response: "What do you think velocity is?"

Pure coaching gold, right?

Open-ended question. Encouraging self-discovery. Empowering them to find their own answer.

Except...

They just stared at me. Confused. Frustrated.

And in that moment, I realized:

I wasn't being helpful. I was actually being annoying.

You see, I had drunk the coaching Kool-Aid.

Every question had to be answered with a question
Every problem had to be solved through self-discovery
Every interaction had to be a "coaching moment"

I had forgotten: Sometimes, people just need to be taught.

How can someone self-discover what they don't know exists?
How can they find their own answers when they don't understand the question?
How can they grow if they're missing the basics?

I had become so afraid of being directive...

So committed to "pure" coaching...

So worried about disempowering the team...

That I had actually disempowered them.

Mistake #3: Stopping My Own Learning

I stopped learning once I earned a few badges. My day-to-day activities grew stale. My energy went down.

I stopped climbing and started coasting. And you know what happens when you coast?

You start going downhill.

I didn't notice it at first. How could I? My teams were still functioning, sprints were still happening, and stories were still getting done.

How I Realized the Mistake?

It happened during a community meetup with other Scrum Masters.

As they shared new techniques, frameworks, and tools, I sat there quietly, realizing something uncomfortable.

I hadn’t learned anything new in months.

I was still relying on the same practices and ideas I’d been using since I got certified. The same scripts. The same approaches.

And honestly? I felt stagnant.

What Was Holding Me Back?

It’s easy to get caught up in the day-to-day demands of supporting a team. I told myself I was “too busy” to invest in my learning.

But the reality was, I stopped prioritizing growth.

How I Fixed It

The fix required something I thought I didn't have: time.

So I made a decision:

Learning wasn't going to be something I did when I had time. It was something I made time for.

I blocked two hours every week for professional development.

Non-negotiable. Like a Sprint Review. It happens, period.

Outcome

I started reading again.

Not just Scrum books.

Books on systems thinking. Organizational psychology. Leadership theories. Anything that could add a new dimension to my practice.

I joined communities of practice. Attended workshops. Started writing about my experiences. Engaged in discussions with other Scrum Masters.

And the rest is history?

The fresh knowledge reignited my passion for the role. My confidence grew, and so did my ability to adapt to the unique challenges of each team.

Fourteen years later, I now have a huge collection of books that I like to show off from time to time.

9 Proven Mental Models for Scrum Masters

Vibhor Chandel — Thu, 17 Apr 2025 07:15:34 GMT

Welcome to the 🔥 free edition 🔥 of Winning Strategy: a newsletter focused on enhancing product, process, team, and career performance. This newsletter shares insights gained from real-world experiences that I gathered working at Twitter, Amazon, and now as an Executive Product Coach at one of North America's largest banks. If you’d like to become a paid member, see the benefits here, and feel free to use this expense template to ask your manager.

I still remember the exact moment I almost quit being a Scrum Master.

Three months into our switch to Agile, I walked into another messy planning meeting. Half the team was late again. Our Product Owner wasn't ready with the work list. And a senior stakeholder had just dumped five "urgent" tasks on us that nobody knew about.

I looked around the room and all I could think was: "What am I even doing here?"

FRUSTRATING! I know…

In case you haven’t discovered it already: A perfect Scrum environment DOES NOT exist.

Most Scrum Masters work in organizations where Agile principles constantly compete with deeply rooted cultures, political dynamics, and resistance to change.

What separates the Scrum Masters who eventually give up from those who succeed isn't better teams or supportive organizations.

No!

It is the armour that successful Scrum Masters create around their mind.

What am I talking about? The Mental Models.

The right mental model can turn a seemingly impossible situation into a solvable problem.

Today, I will share the 9 that helped me navigate the ugliest environments. I’ve used these models to not only survive but thrive in places where teamwork was low and resistance was high.

They serve 2 purposes:

giving you clarity in chaos
providing actionable steps forward

Nothing more. Nothing less.

Let’s get started.

If you’re new, here’s what you missed in the last few weeks

What are Mental Models?

I'm pretty sure you have (or will) at some point in your life (teach or) taught a kid how to tie their shoe laces?

At first, it seems impossible to explain.

The child gets frustrated, the laces get tangled, and you wonder if Velcro might be the better option.

Then someone shows you the "bunny ears" method.

Suddenly, everything in the world changes. The child gets it. What was complex becomes simple. A confusing process transforms into two bunny ears dancing around each other.

That right there? That's a mental model in action.

Mental Model, or MeMod in short, is a simplified way of understanding the world.

We all use mental models every day:

When you check the weather before deciding what to wear, you're using a mental model
When you avoid a restaurant because it was crowded last month, you're using a mental model

As Scrum Masters, we need mental models to help us navigate the complex human nature that no framework or methodology fully prepares us for.

Let’s talk about the 1st one.

MeMod #1: The Serenity Principle

You know that burning feeling in your gut?

The one that shows up when senior management announces another "brilliant" initiative that goes against everything Agile stands for, and you just can’t do anything about it?

Yeah. That one.

The Serenity Principle is effective in moments when you feel those feelings.

The fact is, you can't fix everything.

And you shouldn't try.

The Serenity Principle saved my sanity more times than I can count.

Here’s how it works:

Accept what you can't change
Find the courage to change what you can
Learn to know the difference

THAT'S IT!

Let me give you an example.

Once, as a Scrum Master, the organization I was working with decided to standardize all teams' sprint lengths to two weeks.

No exceptions. No discussion.

Did I like it? NO.

Did I have the power to change it? Also NO.

So instead of burning myself out fighting an impossible battle, I focused on what I COULD control:

Making those two-week sprints the best they could be
Protecting my team's engineering practices
Building trust within my circle of influence

Doing this gave me energy for battles I could win.

Less frustration. Better sleep at night.

Being a great Scrum Master IS NOT about winning every battle.

It's about choosing the right battle.

Spend your time where it matters. Protect your reputation. Attempt to change only what you can.

Let the rest… go!

That’s the Serenity Principle.

Learn it. Live it.

MeMod #2: The 10-10-10 Rule

A decision-making mental model.

How it works:

Ask yourself:

How will I feel about this decision in 10 minutes?
How will I feel about this decision in 10 months?
How will I feel about this decision in 10 years?

How it helps:

This model helps you evaluate the emotional and long-term impact of your rushed decisions.

Example:

Let’s say you’re facing discrimination in your client organization.

If you’re considering escalating discrimination to your parent organization, ask:

Will this feel satisfying in 10 minutes (short-term relief)?
Will this improve my situation in 10 months (professional growth)?
Will this decision affect my career in 10 years (reputation and relationships)?

Let me share a story.

Once, a senior developer publicly criticized the team’s Scrum practices in front of stakeholders.

My immediate instinct? Fight back. Hard.

But I played the 10-10-10 game:

10 minutes? Oh, it would feel GREAT to put him in his place
10 months? Probably a strained relationship with a key team member
10 years? Possibly known as the Scrum Master who couldn't handle criticism professionally

What did I do?

I scheduled a private conversation instead, and we found common ground.

Sometimes, the most satisfying immediate response is the worst long-term strategy.

Read that again.

This rule will help you avoid mistakes.

It will also help you make decisions that your future self will thank you for.

MeMod #3: Anti-Fragility

This is a resilience-building mental model.

Most Scrum Masters aim to be resilient and bounce back from setbacks. But what if you could go beyond resilience and become anti-fragile?

What if you don’t just navigate the storms? You become stronger because of the storms.

This concept, coined by Nassim Nicholas Taleb, represents systems that benefit from disorder. As Scrum Masters, it means viewing every obstacle not as something to merely survive, but as fuel for your growth.

How it works:

See every challenge you face as raw material for your growth. Instead of breaking under pressure, you become stronger because of it.

How it helps:

This mindset lets you reframe tough situations as opportunities
You stop feeling like a victim
You start using every mess, every setback, to build adaptability and grit

Example:

Let's say you're dealing with a team that resists every Scrum event.

Instead of seeing it as a problem, view it as:

A chance to master stakeholder management
An opportunity to improve your facilitation skills
A workshop on influence and persuasion

This mental model doesn't mean you enjoy dysfunction or stop working to improve situations. It means you extract maximum value from difficult circumstances while working to change them.

Instead of asking "Why is this happening?" you ask "What can this teach me that I couldn't learn any other way?"

That seemingly impossible situation? It makes you stronger.

MeMod #4: Hanlon’s Razor

A perspective-shifting mental model.

Ever caught yourself thinking something like: "They're deliberately sabotaging the Sprint!" when faced with uncooperative stakeholders or team members who consistently derail your Scrum practices?

Enter Hanlon's Razor.

What it says:

“Never attribute to malice that which can be adequately explained by ignorance or incompetence.”

In plain English: Most people ARE NOT out to get you. They’re just busy, distracted, or don’t know better.

How it helps:

This model saves you from unnecessary drama.

You stop taking things personally
You stop seeing enemies where there are only misunderstandings

It frees up emotional energy and helps you solve the real problems.

Example:

Let’s say you are a contract-based Scrum Master. Your client’s internal team always seems uncooperative.

Meetings get cancelled. Emails go unanswered.

It’s tempting to think: “They want us out.”

When this happens, apply Hanlon’s Razor and think:

Maybe they’re overworked
Maybe they’re disorganized
Perhaps they don’t realize the impact of their actions

Here’s my story:

Once, a Product Owner repeatedly changed sprint priorities mid-sprint.

Without Hanlon’s Razor, my thoughts were:

"She's trying to prove Agile doesn't work."
"She's out to get me."

With Hanlon’s Razor, my thoughts were:

Is she trained in Agile?
Does she understand sprint commitments?
Is she under pressure from above?

What did I discover?

She was new to the role. No one had explained sprint boundaries to her. Her boss was demanding daily changes.

(Your discovery may be different.)

And the solution?

A coffee chat. Some basic Agile training. Help escalate to her manager.

Lesson? Most people ARE NOT out to get you. They're just trying to get through THEIR day.

Don’t use Hanlon’s Razor to give every other person the benefit of the doubt.

No!

Use it to focus on solutions, not grudges.

MeMod #5: Cargo Cult Thinking

A mental model that saves you from mindlessly following rituals.

During World War II, indigenous islanders in the Pacific observed military forces building airstrips and control towers.

After the war ended, some tribes built wooden replicas of airplanes and control towers, believing that recreating these structures would summon cargo-bearing aircraft.

You might be thinking, "What does this have to do with being a Scrum Master?"

Everything.

Cargo Cult Thinking happens when we replicate practices without understanding their underlying purpose. You see it in:

the daily stand-up, where nobody stands up
the retrospective, where nothing changes
the Sprint Planning, where work is pre-assigned

As a Scrum Master, it's tempting to become the "process police" enforcing Scrum by the book regardless of context. After all, the “guide” says so.

But blindly implementing any framework without understanding why each element exists… well, that’s a recipe for failure.

For example:

Let’s say your team consistently struggles with two-week Sprints.

They often carry user stories over. With a Cargo Cult approach, you’d double down on Sprint discipline: "The Scrum Guide says to stick with a cadence."

A more effective approach is to step back and ask:

"What outcome are we trying to achieve with time-boxed Sprints?"

If the answer is predictable delivery and regular feedback, perhaps you need to adjust the Sprint length, improve story splitting, or consider Kanban, which better suits your team's context.

You don’t abandon Agile values. You thoughtfully apply them to your unique situation.

MeMod #6: The Circle of Control

A mental model that helps you focus your energy where it matters.

Few things are more frustrating than feeling responsible for outcomes you can't control. As Scrum Masters, you often find yourself in this position, i.e. accountable for team performance yet lacking formal authority to make necessary changes.

This is where the Circle of Control mental model guides you.

How it works:

When you find yourself in a situation like this, break it into three buckets:

things that you can control
things that you can influence
things that are completely outside your control

Then?

Zero in on the first two. Let go of the 3rd.

Example:

Recently, Rahul asked this question in the community chat:

You can access the chat conversation here.

If you can’t change how internal teams treat you? Don’t obsess over it.

Focus on:

How can you respond to the situation
Network with supportive team members
Escalate issues professionally, not emotionally

I once worked with a client whose leadership would ignore every suggestion I made.

I stopped trying to “fix” them, even though that was part of the job.

Instead, I built trust with the people who did listen because that’s what I could do then. Eventually, small wins got noticed, and the leaders finally paid attention.

The Circle of Control mental model directs your focus and effort where it counts.

Control what you can. Influence what you can reach.

And…let go of the rest.

MeMod #7: The Law of Diminishing Returns

A mental model that saves you from the trap of endless optimization.

Scrum Masters are natural problem-solvers.

When they see an issue, they instinctively attack it head-on, applying more and more effort until it is resolved. This determination is admirable… until… it becomes counterproductive.

How it works:

Understand this simple truth: After a certain point, putting in more effort doesn’t equal better results. In fact, each extra hour or tweak gives you less and less payoff.

Example:

Let’s say your team’s daily standups keep running longer than 15 minutes.

You’ve already introduced timeboxing and a speaking order, and you've even coached team members on being concise.

Yet, the standups still drag on.

The Law of Diminishing Returns mental model helps us recognize that further effort to tweak the standup process may not yield significant improvement.

Instead, focus on building trust within the team so they naturally self-organize during standups. For now, accept that some inefficiency is okay while the team matures.

This mental model is your permission to quit…strategically.

Don’t confuse persistence with productivity. Know when enough is enough.
Then, move on to what matters more.

MeMod #8: Entropy

This mental model teaches us that without continuous energy input, things fall apart. This fundamental law of physics applies to your Scrum team as it does to the universe.

As Scrum Masters, you expect that once good practices are established, they will continue running smoothly.

But entropy teaches us that disorder is the default state.

Without ongoing attention, even the most well-designed processes will deteriorate.

Consider your team's information radiators. Without regular updates, they become outdated
Your working agreements? Without reinforcement, they fade into forgotten documents
Your retrospective action items? Without follow-through, they become empty promises

That’s how nature works! Excellence requires continuous energy input.

Great Scrum Masters recognize that maintaining high performance is an active, ongoing process.

Years ago, when I embraced entropy as a mental model, I stopped being surprised when things slipped. I built regular "entropy-fighting" activities into my routine, like:

Periodic refreshers on core principles
Regular validation of working agreements
Continuous refinement of processes (yes, even Scrum)

Rather than viewing this maintenance as a sign of failure, I recognized it as an essential part of the job, like changing the oil in a car.

Entropy isn't your enemy.

It's simply a reality that effective Scrum Masters acknowledge and plan for.

MeMod #9: Multiply by Zero

No matter how large a number, multiplying it by zero always yields zero.

This principle applies with surprising accuracy to Scrum teams, and it's a lesson I learned the hard way.

Several years ago, I witnessed a team that excelled in nearly every aspect of Agile development. Their technical practices were outstanding. Their velocity was stable. Their code quality was excellent. Sprint after sprint, they delivered completed features exactly as planned.

Yet the product failed.

Why?

Because one critical factor was missing: They built features nobody wanted. All that brilliant effort multiplied by zero stakeholder validation equalled zero market value.

That’s "Multiply by Zero" mental model.

When a critical success factor is completely absent (zero), the exceptional quality of other elements becomes irrelevant, and the end result always…is zero.

Recognize your team's potential "zeros". Some common examples are:

Zero stakeholder engagement = zero market fit
Zero testing discipline = zero product reliability
Zero team psychological safety = zero innovation
Zero product owner availability = zero direction clarity
Zero technical excellence = zero sustainable delivery

Your role as a Scrum Master is to identify these potential zeros before they nullify your team's hard work.

This often means having uncomfortable conversations with your team.

For example, if your Product Owner rarely engages with stakeholders, you must ask your Product Owner:

"Are we confident we're building the right thing? What's our risk of multiplying all this development effort by zero user value?"

A chain is only as strong as its weakest link.

Don’t let your zero go unnoticed.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Only available to Paid Subscribers.

The Journey Forward

You now have my 9 mental models.

These are real tools (not theory) to help you navigate the mess, uncertainty, and opportunities of your unique Scrum Master journey.

Remember: mastery has nothing to do with perfection, memorizing rules, or checking boxes. It’s about clarity. It’s about focus. It is about courage to do what matters, especially when things get tough.

You’ll have moments of doubt.

It is not just the Scrum Master role; life, in general, is tricky. It happens with all kinds of roles.

But with these models, you’ll catch yourself faster, reorient more easily, and avoid the traps that keep most people stuck.

So what’s next?

Pick one model and try it this week
Apply it deliberately
Document insights
Develop your variations (customize)
Create context-specific applications
Build your example library
Mentor others

The most powerful tool in leadership IS NOT the authority you possess, it is the mental models you use to understand and shape the world around you so you can INFLUENCE it the way you need.

Stay curious. Stay humble.

And keep moving.

Show your support

Every post on Winning Strategy takes 3 days of research and 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly recommend that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Available for iOS and Android

Research

https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2022.873289/full
https://web.wpi.edu/Images/CMS/SSPS/06.pdf
https://github.com/AdrienLemaire/awesome-mental-models
https://www.pnas.org/doi/10.1073/pnas.1012933107
https://zapier.com/blog/mental-models/
https://www.reddit.com/r/coolguides/comments/1bgdmp9/a_cool_guide_cheatsheet_to_mental_models_with/
https://seagrant.oregonstate.edu/sites/seagrant.oregonstate.edu/files/h11002.pdf
https://thesystemsthinker.com/mental-models-and-systems-thinking-going-deeper-into-systemic-issues/
https://en.wikipedia.org/wiki/Mental_model
https://www.pnas.org/doi/10.1073/pnas.1012933107
https://www.goodreads.com/shelf/show/mental-models
https://fs.blog/mental-models/

Connect With Me

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America's largest banks.

Share Winning Strategy

The Irony of Scrum Master Role

Vibhor Chandel — Thu, 03 Apr 2025 07:15:41 GMT

Quick question:

When was the last time someone told you that your Retrospective technique needs work?

Or that your impediment resolution approach is too passive?

Or that your Sprint Planning facilitation could be more focused?

Can't remember? I'm not surprised.

As a Scrum Master, it often feels like you're drowning in a pool of "everything's fine" and at times, complete silence for feedback while you strive to determine if you're truly making an impact... and whether you are growing in your role.

It's ridiculous, really.

You spend your days:

helping teams have difficult conversations
teaching others how to give constructive feedback
creating safe spaces for honest communication
encouraging transparency

Yet somehow, you're stuck in the feedback torture.

your team avoids criticizing you
your Product Owner dodges performance discussions
your peers offer only superficial praise

And as a result…

You're left guessing whether you're truly effective or just really good at making people comfortable enough to avoid difficult conversations.

The IRONY?

You know exactly what good feedback looks like; you facilitate it daily.

You just can't seem to get it for yourself.

Let's fix that.

If you’re new, here’s what you missed in the last few weeks

Subscribe now

Why do Scrum Masters struggle to get honest feedback?

Let’s face it, getting genuine, constructive feedback is an uphill battle for Scrum Masters.

Not because your team doesn’t care or because you’re bad at your role.

NO!

Because the psychology of your position works against you.

Here’s what I mean:

You’re seen as a neutral party.
You’re not the boss. You’re not subordinate. You’re Switzerland. People don’t feel like they owe you feedback, positive or negative
You’re the “nice one.”
You’re the person who listens, supports, and helps solve problems. Giving feedback to someone who’s always helping? Awkward.
Your impact is subtle.
Scrum Masters don’t deliver code. They don’t set priorities. Your influence is invisible, so people struggle to measure your effectiveness
People fear breaking the balance.
You’ve built trust. You’ve created psychological safety. Many team members worry that giving you feedback could disrupt that balance

And therefore you get:

Silence!
Surface-level compliments!
And a lot of “you’re great, keep doing what you’re doing!”

Which, let’s face it, isn’t helpful.

For the persistent ones:

Here are 6 research-based methods to extract valuable feedback from your team.

Method #1: Ask About Specific Situations, Not General Feedback

What do you think of the following question:

"How am I doing as a Scrum Master?"

Here’s what I think: It’s a terrible question guaranteed to get you nowhere.

Why?

Because it's too big, too vague, and frankly, too intimidating for most team members to answer honestly.

Here are some popular responses to this question:

"You're doing great!"
"Everything's fine!"
Silence and crickets

So, stop asking the general question.

What you need to do is ZOOM IN on specific MOMENTS.

Try these:

"What could we improve about how I handled yesterday's impediment with the testing environment?"
"During last week's refinement, did the visualization technique help or hinder your understanding?"
"Was there anything I could have done differently when the conflict between Dev and QA emerged?"

Then, go one step deeper:

“What would you change if we faced the same situation again?”
“Was there something I could have done to make it easier for you?”

What’s the difference?

You're not asking them to evaluate YOU. You're asking them to evaluate a MOMENT.

It's safer. It's concrete. And it's actionable.

Humans are wired to recall and analyze specific events far better than they can provide general evaluations. You're essentially hacking their brains to give you what you need.

Thing to remember: Specific questions get specific answers. And specific answers are the only ones you need.

Method #2: Share Your Own Weaknesses First

Want to make people comfortable giving you the HONEST feedback?

Start by being honest about your flaws.

Drop the "Perfect Scrum Master" mask
Admit your struggles
Get vulnerable

Yes, I know...it’s a little difficult. Be genuine, though. Don’t make up stuff.

You can try these:

"I noticed I tend to talk too much in refinement sessions..."
"Sometimes I get impatient when issues aren't resolved quickly..."
"I probably overdid it with the sticky notes in that last retro..."

This shows your team you’re not just fishing for compliments, you’re genuinely looking to improve.

You're not the "feedback expert" anymore. You're just another human.

People LOVE helping humans who admit they're not perfect.

Be as specific as you can, like:

"Remember that planning session where I kept interrupting?"
"You know how I got defensive about that Kanban suggestion?"
"That retro where I pushed too hard for answers?"

Not like:

"I'm not perfect..."
"I make mistakes..."
"I have things to work on..."

Too vague. Too safe. Too useless.

Method #3: "What’s One Thing?" Questions

When it comes to feedback, less is more.

Big, open-ended questions like “What can I do better?” can overwhelm people. They don’t know where to start, so they just… don’t.

So shrink the ask.

The "What's One Thing?" technique is brilliantly simple: It limits the scope to make answering manageable.

For example, instead of this:

"How can I improve as a Scrum Master?"

Try this:

“What’s one small thing I could do differently to make your work easier?”
“What’s one thing I could stop doing that might help our team?”
“What’s one thing you wish I did more often?”

You're not asking for a comprehensive evaluation of your professional identity. You're asking for a single, specific adjustment.

These questions are simple.

They lower the pressure, making it easier for your team members to give you actionable feedback.

One thing? Anyone can think of one thing.

Method #4: Future Pacing

Here's a psychological trick for extracting the HONEST feedback:

Don't ask about the past. Ask about the future.

Why?

Because:

Past = Criticism
Future = Helping

Future pacing is a psychological technique that moves the conversation from backward criticism to forward improvement. And it works wonders for Scrum Masters seeking honest feedback.

Here’s how to do it. First say:

"In our next Sprint Planning..."
"When we run the next big retro..."
"For future impediments..."

Then add:

"...what could I do differently to make it better?"

None of these questions requires anyone to criticize what you've already done. They don't have to say "you messed up.” They have to imagine a better future.

And…

While they're describing what could be better next time, they're actually telling you what wasn't working before. You're getting the feedback you need, just packaged in a way easier for them to deliver.

Method #5: Use Team Feedback as a Starting Point

Direct questions about your performance can make team members uncomfortable.

So don't make it about you... at first.

Start with the team as your focus, then gradually zoom in.

Begin by asking broader questions:

"What habits do you think our team has fallen into that might be holding us back?"
"If you could change one practice about how our Scrum events run, what would it be?"
"What's something our team consistently struggles with during Sprint execution?"

These questions are about "us," not "you."

Team members can speak freely because they're diagnosing the system, not evaluating a person.

Once this conversation is flowing naturally, you PIVOT…slightly:

"And for me specifically, as your Scrum Master, what's one thing I could do differently to help address these team challenges?"
"How might I better support the team in overcoming that obstacle we just discussed?"

By starting with a focus on the team, you create a safe space for discussion. Then, when the moment is right, you shift the focus to yourself without making it feel intimidating.

You create a bridge from team feedback to personal feedback.

This progression feels natural.

And the result?

Honest, actionable feedback without putting anyone on the spot.

Method #6: Layered Feedback

This method creates a step-by-step path to honest communication.

Just like peeling an onion, you start with the outer, safest layers before reaching the core:

Here’s how to do it:

Start broad, then gradually get more specific:

Layer 1: Begin with an open question:

“How do you think things are going overall?”

Layer 2: Move to team-level feedback:

“What could we do better as a team?”

Layer 3: Transition to personal feedback:

“What’s something I could do differently to support you better?”

Layer 4: End with a specific example:

"In yesterday's refinement session, was there anything I could have done differently when facilitating the estimation discussion?"

This technique works because:

It creates a psychological momentum. Once someone starts providing feedback, they're more likely to continue
It establishes a feedback-friendly context before asking the harder questions
It gives the person time to organize their thoughts
It feels natural

People feel SAFE in this approach.

And when people feel safe? That’s when the best insights surface.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Only available to Paid Subscribers.

When Is the Right Time to Ask for Feedback?

Timing is everything when it comes to feedback.

Choose the right moment, and you’ll get thoughtful, honest insights. Ask at the wrong time, and you might get hesitation or worse, silence.

Avoid these times:

Right after a crisis. When the team is recovering from a production issue or missed deadline, they're in survival mode. Their feedback will be more negative and reactive rather than thoughtful
During high-stress periods. If your developers are racing to finish a Sprint or preparing for a major demo, your request for feedback becomes one more demand on their limited bandwidth. Check out the post — Why Developers Hate Scrum And How To Fix It?
In large group settings. Few people will offer honest criticism when surrounded by peers. The social risk is too high

Look for these times:

After small wins. Following a successful Sprint or release, team members are more receptive
During 1:1s. Private conversations remove the audience effect and create space for vulnerability on both sides
At natural transition points. Sprint Retrospectives, quarterly reviews, or project completions are natural moments of reflection when people are already in an evaluative mindset
When you've demonstrated change. After you've visibly implemented previous feedback, people are more motivated to offer new insights because they see you actually use them
During moments of connection. Sometimes the best feedback comes during unplanned interactions like a coffee break after a meeting, when defenses are down

Also, remember that different team members may have different optimal timings. Some may need time to process and may prefer sending thoughts after reflection. Others may speak honestly in the moment.

It’s a human thing. We’re all humans.

The Journey Forward

Asking for feedback isn’t easy, but it’s one of the most powerful ways to grow in your role.

As you implement these six methods, remember to start small.

Choose one technique that resonates with you and try it. Notice what happens not just in the responses you receive, but in how the energy shifts between you and your team.

Over time, you'll notice that as seeking feedback becomes your habit, giving feedback becomes their habit. The feedback conversations will begin happening naturally.

And it all begins with you having the courage to ask yourself: "How can I be better?"

So take that first step.

Show your support

Every post on Winning Strategy takes 3 days of research and 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly recommend that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Available for iOS and Android

Research

https://support.cultureamp.com/en/articles/7048450-the-science-behind-team-feedback
https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2022.938699/full
https://reachinbox.ai/blog/professional-feedback-request-email-template/
https://pmc.ncbi.nlm.nih.gov/articles/PMC9355701/
https://www.betterup.com/blog/how-to-ask-for-and-receive-feedback
https://pmc.ncbi.nlm.nih.gov/articles/PMC7304587/
https://www.skillpacks.com/how-to-request-feedback-from-coworkers/
https://www.gallup.com/workplace/357764/fast-feedback-fuels-performance.aspx

Connect With Me

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America's largest banks.

Share Winning Strategy

How to Turn Resistance into Support

Vibhor Chandel — Thu, 13 Mar 2025 07:15:32 GMT

Hi Everyone,

Something extraordinary happened at work last week, and I can’t stop thinking about it.

It was during a particular high-stakes meeting with the C-suite, an event meant for the company's highest-ranking people.

Yet, somehow, a junior manager walked into the room (how she got the meeting invite is still a mystery to me).

She wasn’t just the least experienced person in the room but also the lowest-ranking.

What happened next left me amazed.

She took control of the room.

She won over the executives, one by one.

I watched her transform a room full of skeptical executives into advocates and, most importantly, “initiate” a change that our organization desperately needed but everyone was too afraid to address.

It wasn’t luck.

It wasn’t arrogance.

It was a masterclass in how to challenge the status quo while building bridges, not burning them.

And as I observed her, I realized there were lessons here that every Scrum Master could learn.

Lessons about courage, leadership and organizational psychology.

Let me take you through what I witnessed.

Let’s get started.

Here’s what happened

This was the quarterly strategy review meeting — a “sacred” ritual where the C-suite gathered to make decisions that would shape the company's future. The kind of meeting where even VPs waited for invitations.

But as the saying goes — “Power moves in silence.”

A junior manager — new to the company, still earning her credibility — walked into this meeting with a proposal that threatened the status quo.

As she presented, I could sense the collective thought bubble saying: 'Who invited her?'

I could feel the resistance.

After hearing the first “no,” at that moment, she had two paths:

Path 1: Double down with data. Talk louder. Push harder. Defend every detail.

Path 2: Create space for concerns.

She chose the second path. And I’m so glad she did that.

Because the first path was an obvious ticket out of the company.

What she did was subtle yet so powerful.

She put down her carefully prepared presentation (this is important to note), looked around the room, and simply said:

“Please help me find what I’m missing.”

These 7 words completely transformed the dynamic in the room.

For a moment, there was utter silence.

A normal person would sweat with anxiety, thinking, “Why did I do this…”

She? She…waited.

Her patience paid off, and comments began to come in.

But that’s not the amazing part.

The amazing part is how she handled those comments.

9 Signs You Have a Good Manager

Vibhor Chandel — Sun, 09 Mar 2025 08:15:46 GMT

Being a Scrum Master puts you in a unique position.

You guide others, but who guides you?
You coach teams, but who coaches you?
You remove impediments, but who removes yours?

This is where having the right manager becomes extremely important.

But…there is one problem!

How do you know if your manager truly understands the complex nature of your role?
How can you tell if they can actually support your growth as a Scrum Master
How do you build a partnership that enhances your effectiveness and career trajectory?

This is a challenge.

A challenge that every Scrum Master faces at some point in their career.

The relationship between a Scrum Master and their Manager IS NOT like other reporting relationships. It requires a unique understanding of:

servant leadership,
organizational change, and
the delicate balance between influence and authority

Having coached hundreds of Scrum Masters and “managed” some, I've noticed some effective ways of doing this.

These ways differentiate Scrum Masters who thrive from those who struggle in their roles and careers.

It often comes down to the quality of support you receive from your Manager.

In today's post, I'll share:

9 clear indicators that you have a manager who truly gets your role
How to leverage this relationship for career growth
Practical strategies to strengthen this crucial partnership

Let's get into it.

#1 They Advocate For You

A great manager doesn't just understand the Scrum Master’s role — they actively advocate for it.

How does this advocacy show up in practice?

When you have the right manager, you'll notice they:

consistently highlight your contributions during leadership meetings
ensure your work is visible to stakeholders who matter
position you as a strategic partner rather than just a "process person"

When your manager advocates for you, they reinforce your authority and influence within the organization.

I've seen firsthand how this transforms the impact of what Scrum Masters do.

When your manager introduces you as "our agile transformation expert" rather than "our meeting facilitator," it fundamentally changes how others see your role.

Most importantly, it aligns with the principles of servant leadership.

When your manager advocates for you, it allows you to focus on what really matters: coaching the team and promoting continuous improvement, instead of constantly justifying your value.

#2 They Provide Leadership Air Cover

Even the most skilled Scrum Masters need someone to watch their back.

A great Manager stands behind your decisions when it matters.

When leadership questions why you spend time on team dynamics rather than "just finishing the sprint," a good manager doesn't throw you under the bus.

They explain:

"Our Scrum Master is addressing the root causes that will make this team sustainable in the long run, not just for this sprint."

This backing happens in meetings you're not even part of, where important perceptions about your work are being formed. A manager who provides air cover ensures your decisions ARE NOT undermined when you're not in the room to defend them.

They help you navigate organizational politics.

Let's be honest — implementing agile values often means challenging established power structures and comfortable habits. Good managers:

alert you to potential resistance before you encounter it
share context about historical attempts at change
offer insights about stakeholders' unspoken concerns

This political intelligence is invaluable.

One Scrum Master I worked with (no, I didn’t manage him) puts it like this:

"My manager's heads-up about the VP's previous failed agile initiative saved me from making the same mistakes and losing credibility."

That's what real support looks like.

They don’t protect you from accountability. They ensure you can focus your energy where it matters most, i.e. helping teams embrace Agility and deliver value.

#3 They Value Your Indirect Impact

A great Manager knows that traditional performance metrics can’t always measure the Scrum Master’s impact.

They don't just look at numbers — they see the whole picture.

They're more interested in the meaningful indicators of your effectiveness:

How has psychological safety improved since you began working with the team?
Are stakeholders experiencing greater transparency in the development process?
Has the team's ability to adapt to changing requirements increased?

These outcomes don't fit neatly into spreadsheets but are the true measure of a Scrum Master's impact.

They celebrate when you report:

How To Be A Proactive Scrum Master?

Vibhor Chandel — Thu, 06 Mar 2025 08:15:47 GMT

Let me tell you the truth about Scrum Masters that nobody wants to admit.

Most Scrum Masters are “Reactive.”

Now, what do I mean by that?

They wait for problems to emerge. They wait for team members to ask for help. They think their job is to facilitate meetings and update charts.

But the best Scrum Masters? They operate differently.

They anticipate needs before they're expressed. They don't just solve problems—they prevent them from occurring in the first place.

They are “Proactive.”

The question now arises:

How do you stay ahead of problems when you're already busy managing daily team activities?

If you don't get ahead of issues, you'll always be reactive
If you try to do too much, you might burn out

This puts you in a tough spot.

Over the years, I have compiled a list of several activities that I observed successful leaders engage in to be proactive. 12 of these pertain to the role of a Scrum Master.

Myth:

As a “Proactive” Scrum Master, you do more things.

Reality:

As a “Proactive” Scrum Master, you do the same things “differently.”

After working with so many different Scrum Masters at all levels, I’ve noticed that the best ones aren't working longer hours. They're just more intentional about what they do during those hours.

In this post, I'll share 11 specific activities that transform “Reactive” Scrum Masters into “Proactive” leaders.

No theory.

No fluff.

These are practical, proven activities you can start using tomorrow.

Let’s get started.

If you’re new, here’s what you missed in the last few weeks

Subscribe now

#1 — Summary and Confirmation

This is where many Scrum Masters drop the ball.

They think their job is done when the meeting ends.

No!

Your job is to create clarity.

Meetings don’t create clarity. Summaries of the meetings do.

It’s easy for people to misinterpret what was discussed in the meetings and events, and it’s even easier for action items to slip through the cracks.

As a proactive Scrum Master, you don’t let that happen.

At the end of every meeting (or event), take two steps:

Summarize the key points discussed
- highlight decisions made and why they matter
- call out any blockers or risks uncovered during the conversation
- keep it concise — nobody needs a second meeting at the end of the first one
Confirm action items
- Who is doing what?
- What are the deadlines?
- Are there any dependencies or follow-ups needed?

When everyone leaves the meeting with the same understanding, you avoid confusion, rework, and wasted time.

Here’s how you do it:

set a timer for 5 minutes before the scheduled end time
say, "Let me summarize what we've discussed and agreed upon..."
list the key decisions made
clearly state each action item with an owner and deadline
ask explicitly: "Does anyone understand anything differently?"

No confusion. No missed tasks. No wasted time.

Red Flag to Watch:

If you can't summarize the key points of a meeting in 3 minutes, that's a signal that your meeting might have been unfocused. Use this as feedback to improve your facilitation skills.

Start doing this today, and you’ll immediately notice the difference.

#2 - Following up

You have captured the “action items.”

That’s a great first step, but that’s not it.

Action items don’t complete themselves.

People get busy. Priorities shift. Tasks are forgotten.

As a proactive Scrum Master, you don’t leave action items floating in the void. You “follow up.”

Following up IS NOT micromanaging. It’s ensuring progress and removing blockers.

Here’s how to do it effectively:

Check progress at the right time:
1. not too early because that feels like micromanaging and creates resistance
2. not too late because then you're just fighting fires and managing crises
3. just right, when you can still make a difference and provide meaningful support
Keep it casual and supportive:
1. Have quick hallway conversations like "Hey Tim, how's that documentation update going? Need any help?"
2. Drop friendly messages checking if there are any blockers you can help remove
3. Make it easy for team members to ask for help without feeling pressured

The goal IS NOT to create stress around action items. The goal is to ensure everyone has what they need to succeed.

For example:

When something is due on Friday, a quick check-in on Wednesday morning gives you enough time to help if needed.

Not being proactive:

Let’s say a team member is responsible for identifying a dependency with an external team, but they’re stuck waiting on an email response. Days go by, and now your Sprint is at risk.

Being proactive:

You check in 3 business days after the meeting. The team member says, “I’m still waiting on a response.” You step in, escalate the issue, and get a resolution within an hour.

Red Flag to Watch:

If you find yourself constantly chasing the same people for updates, ask:

Are the action items unclear?
Are the deadlines unrealistic?
Does this person need additional support or training?

If team members appear defensive or uncomfortable during your follow-ups, you might be coming across more as policing than as supporting. Take a step back and adjust your approach.

Follow-up strategy:

One strategy that has worked for me is to "schedule follow-ups.”

Everyone on the team understands that an action item requires a follow-up within a specific timeframe (between 3-5 days). Work together as a team to agree upon this timeframe and incorporate it into your working agreement.

Following up is about building trust. Your team must know you’re there to help, not to nag.

#3 — Maintain working agreements

Most teams create working agreements at the start.

And then?

They forget about them.

The document gets tucked away in some folder, never to be seen again.

This….should not happen.

Working agreements are living documents.

They reflect how the team works together and what they value. As the team evolves, so should the agreements.

As a proactive Scrum Master, you don’t just help your team create working agreements — you maintain and update them.

Here’s how you can ensure working agreements stay relevant:

Review them regularly.
- set a reminder to review working agreements at least once per quarter—more often if the team is new or going through changes
- use Sprint Retrospectives as a natural time to revisit them
Watch for signals that updates are needed.
- meetings consistently running over time
- team communication off the track
- team members are unclear about expectations
- new team members joining or leaving
- recurring conflicts
- changes in team structure
Updates as a team.
- ask your team: “What’s working (and what’s not) in how we collaborate?
- Encourage everyone to suggest changes
Keep it visible.
- post them somewhere visible — like a Confluence page or a team Slack so they stay on top of mind
- always send a copy of agreements as part of the agenda

Example:

Let’s say your team has a working agreement about starting Daily Scrum at 10:00 AM sharp, but half the team is consistently late.

Instead of ignoring it, you bring it up in the Retrospective:

"Hey, I noticed we’re struggling to start on time. Does 10:00 AM still work for everyone? Should we adjust the time or find another solution?"

Don’t force everyone to come on time. Adjust.

Red Flag to Watch:

If working agreements are ignored, ask yourself:

are they too vague?
do they reflect how the team actually works?
did the team have a say in creating or updating them?

Working agreements are not the rules. They're tools to help your team work better together.

#4 — Conduct regular training

Many Scrum Masters assume training is a one-time thing.

Big mistake.

Teams don’t grow by accident.

They grow through continuous learning.

As a proactive Scrum Master, you don’t wait for someone to ask for training. You take the lead in identifying gaps and opportunities to help the team level up.

Here’s how to be proactive with team trainings:

Identify learning needs.
- are team members struggling with story slicing?
- is there confusion about Velocity or capacity planning?
- do they need a deeper understanding of Scrum values or Agile principles?
- pay attention to Retrospectives, Sprint Reviews, and everyday conversations. These are goldmines for uncovering gaps
Keep them short and practical.
- nobody wants to sit through a 3-hour lecture.
- focus on bite-sized topics that can be applied immediately, like “How to write better user stories” or “Tips for effective backlog refinement.”
Mix it up.
- you don’t have to deliver every session yourself
- bring in experts, share online resources, or host lunch and learn where the team learns together
Make it a habit.
- schedule training sessions at regular intervals — maybe once per Sprint or once a month.
- treat it like any other team activity that adds value

Learning is never “done.”

Read the post below to get ideas on scheduling a year’s worth of training sessions:

1-Year Training Plan for Scrum and Agile Teams + Template

Red Flag to Watch

If your training sessions have low engagement or attendance, you're either picking the wrong topics or delivering them at the wrong time. Adjust based on team feedback.

Training IS NOT about teaching for the sake of teaching. It’s about solving real problems.

#5 —

Monitor team metrics

Metrics are powerful — but ONLY IF you use them the right way.

Most Scrum Masters either ignore team metrics altogether or obsess over them without understanding their purpose.

Reactive Scrum Masters track metrics because "it's required."

Proactive Scrum Masters use metrics to “spot patterns” before problems occur.

The simple activity:

Regularly analyze key team metrics to uncover hidden truths about how work flows.

Focus on just a few meaningful metrics (whatever they are):

Velocity trends (stability vs. volatility)
Cycle time (where work gets stuck)
Quality indicators (bugs, technical debt)
Sprint burndown patterns
etc.

The power is in the conversation, not the collection:

Review “trends” weekly, not just current numbers
- Example: Is velocity consistently increasing? Is cycle Time gradually decreasing?
Ask "why" multiple times when you spot irregularities
Bring observations to the team as questions
- “I noticed our Cycle Time has been increasing. Are we facing new blockers?”
- “Our Velocity has been consistent for three Sprints — great job! Is there anything we can do to sustain this?”

Turn data into action.

For example:

Let’s say your team’s Sprint Burndown consistently shows a sharp drop in completed user stories during the last two days of the Sprint.

Instead of ignoring it, you bring it up in the Retrospective:

“I noticed we tend to finish a lot of work right before the Sprint ends. Is this a sign we’re not breaking down tasks enough or overcommitting?”

This opens the door to solutions like better backlog refinement or reducing Sprint's scope.

Red Flag to Watch:

If you collect metrics that never drive action, you're just creating busy work. Every metric should answer a question that matters to your team.

Good metrics start conversations. Great metrics inspire action.

#6 — Create an impediment board

Most Scrum Masters keep impediments in their head. That's like trying to juggle blindfolded — eventually, something important will drop.

An impediment board makes blockers visible, trackable, and, most importantly, resolvable.

Set Up Your Impediment Board

Option #1 — If the impediments impact the ongoing work, it is preferable to include them on the Scrum Sprint board as user stories.

Option #2 — If the impediments are well recognized and may require more time than the sprint's duration, it is advisable to keep them on a separate Kanban board.

Keep the Kanban Board simple:

Basic Columns:

Identified
In Progress
Waiting External
Resolved
Parked (for items that can't be resolved now)

Track the following for each impediment:

Description of the impediment
Impact level
Date identified
Owner
Next action
Target resolution date

Learn more about how to manage impediments in the posts below:

For example:

Let’s say your team is blocked because they’re waiting on access to an external API. The request has been stuck in approval for over a week.

Instead of letting the team struggle, you:

Log the issue on the Impediment Board
Follow up with the responsible person daily
Escalate to leadership if necessary

An impediment board is only as effective as the actions it drives.

#7 — Network with other Scrum Masters

Scrum Masters don’t work in a bubble.

Your team operates within a larger ecosystem of other teams, departments, and stakeholders. And often, cross-team dependencies become the biggest blockers to progress.

As a Scrum Master, building strong relationships with other Scrum Masters and departments is important.

It helps you identify and resolve these dependencies early.

How to do it:

Connect regularly with other Scrum Masters
- Set up check-ins to share updates, discuss overlaps, and align on priorities
- Join an existing Community of Practice
Spot dependencies early
- During backlog refinement, ask: “Do we need anything from another team or department?”
- Proactively reach out those teams (Scrum Masters) and align timelines
Facilitate cross-team conversations
- Don’t wait. Act as a bridge between teams to clarify needs and resolve conflicts
Escalate when needed
- If a dependency is beyond your control, escalate with clear data and proposed solutions

Suggestion:

Strong relationships are built “before” they're needed.

Invest time building and maintaining these connections even when there aren't immediate problems to solve.

#8 — Conduct pre-refinement sessions

Refinement sessions often waste valuable developer time on unprepared stories.

As a proactive Scrum Master, you can help the Product Owner by conducting pre-refinement sessions to ensure stories are clear, prioritized, and actionable before they’re presented to the team.

How to Run Pre-Refinement Sessions:

meet with the Product Owner for 30-60 minutes weekly
review stories planned for the next team refinement
check for clear acceptance criteria, business value, and dependencies
identify which stories need more work before team review

For example:

Start with the story's core – its business value.

Help your Product Owner articulate why this story matters and how it benefits users. This foundation guides all other refinement decisions.

Next, examine the story structure. Is it too large? Does it hide multiple stories within? Break down epics into digestible pieces that the team can estimate and deliver within a sprint.

Then focus on clarity. Each story needs:

A clear, specific goal
Well-defined acceptance criteria
Documented assumptions and constraints
Identified dependencies and risks
Supporting materials (mockups, workflows, technical specs)

Note: Your goal isn't perfection – it's preparation. Create enough clarity to enable productive team discussions while leaving space for the team to shape the implementation approach.

#9 - Casually reinforce Agile values

Agile is a “mindset.” We all know that.

As a Scrum Master, one of the most impactful things you can do is casually reinforce Agile values in everyday conversations.

These subtle reminders help the team internalize Agile principles without feeling like they’re being “taught.”

For example:

When you see the team demonstrating Agile values, call it out in a natural way:
1. “That’s a great example of collaboration!”
2. “I love how we’re responding to change instead of sticking rigidly to the plan.”
When helping the team make decisions, frame it through the lens of Agile:
1. “Since our highest priority is delivering value, what’s the smallest increment we can deliver?”
2. “Let’s prioritize working software over detailed documentation here.”
Use phrases from the Agile Manifesto or principles to normalize them in conversation:
1. “How can we get fast feedback on this?”
2. “Let’s focus on simplicity — the art of maximizing the amount of work not done.”

Let’s say during a Daily Scrum, a team member mentions they pivoted to address a new customer need.

You casually say, “That’s a perfect example of responding to change over following a plan — awesome!”

Keep it informal and avoid sounding preachy. The goal is to make Agile values feel natural, not forced.

#10 — Periodically remind DoD

The DoD is more than just a checklist. It’s a commitment to quality.

But over time, teams can lose sight of it.

As a proactive Scrum Master, it’s your job to remind the team of their DoD and ensure it remains central to how they deliver work.

Here’s how:

Choose natural moments to bring attention to the DoD:

Bring it up during events:
- In Sprint Planning: "Before we take on these stories, let's remember what 'Done' means for us. Are we confident we can complete everything on our checklist for each of these items?"
- During Daily Scrums: When someone's about to complete a task, gently ask, "How are we tracking against our Done criteria for this one?"
- During Refinement: "As we size this story, let's remember everything that needs to happen to call it truly Done."
Other opportunities to remind DoD:
1. when a team member is about to mark something complete
2. during the final days of a sprint when finishing touches matter
3. when discussing acceptance criteria for new stories
4. after incidents that might suggest a DoD gap

Red Flag to Watch:

If the team consistently misses parts of the DoD, ask yourself:

Is the DoD realistic and achievable?
Does the team understand the importance of the DoD?

By periodically reinforcing the Definition of Done, you help the team maintain a high standard of quality and deliver “consistent” value.

#11 — Celebrate sprint completion

Celebrations matter, even small ones.

Marking the end of each sprint with a moment of acknowledgment helps create positive associations with sprint completion.

Keep it light and quick

End each sprint with a brief celebration that fits your team's culture:

Option #1: Share a quick summary:

"Great sprint, everyone! We completed 8 stories, resolved 3 bugs, and delivered feature X!”

Option #2: Post a relevant GIF:

Choose something that matches the sprint's theme or inside jokes. Maybe it's a:

“victory dance” for hitting all goals, or a
“tired-but-proud” reaction for a challenging sprint

Make it meaningful

Vary your approach based on the sprint's character:

For achievement-filled sprints:

highlight specific wins and their impact
share positive customer feedback
note team members who went above and beyond

For challenging sprints:

acknowledge the hard work
highlight lessons learned
express confidence in the team's resilience

You don’t need an elaborate ceremony.

A quick moment to pause, acknowledge the work, and transition positively into the next sprint is sufficient.

🎁 Notion Template: Proactive Scrum Master

I've developed a Notion template to help you implement what you've learned. This template allows you to systematically incorporate actionable steps into your daily routine, helping you create a proactive mindset.

You can download the template here: 🎁 Proactive Scrum Master Template

In Closing

A Proactive Scrum Master shapes culture through small, consistent actions rather than grand gestures.

These 11 micro-interventions require minimal time but yield compounding benefits.

Keep in mind: Your presence matters more than your presentations. Your questions create more change than your answers.

Start with just one of the above this week. Notice what happens. Add another next week.

You don’t have to know everything. You just do the right small things consistently.

Show your support

Every post on Winning Strategy takes 3 days of research and 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly recommend that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Available for iOS and Android

Connect With Me

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America's largest banks.

Share Winning Strategy

9 Books To Become An Exceptional Scrum Master

Vibhor Chandel — Sun, 02 Mar 2025 08:15:43 GMT

For those who don’t know — I am a book nerd.

If a new book is published on a topic that I deeply care about, I either buy it or spend hours at the bookshop reading it within the first week of its launch.

“It is crazy!”

I know this because my family, friends, and the staff at Indigo, my local bookshop, have told me.

But, this habit — or obsession, as some might call it — has done wonders for me.

It made me exceptional at what I do.

I have this ability to find answers to seemingly complicated problems.

I don’t take the credit for that, though.

The credit goes to my collection of books (1855 books and counting) and a “system” of notes I have curated over many years.

This gives me an unfair advantage in certain things, including when it comes to recommending books.

Spoiler Alert: These are not the everyday “Scrum” or “Agile” books.

No!

Of course, if you want to learn the "mechanics of Scrum," the following are sufficient:

The Scrum Guide
Agile Project Management with Scrum
Essential Scrum
Scrum Mastery
etc.

But!

If the “goal” is to become an "exceptional" problem-solving machine, these traditional resources only scratch the surface.

Why?

Because those who are exceptional need expertise in:

Behavioural psychology
Change management
Conflict resolution
Team dynamics
Systems thinking
Organizational design
etc. etc. etc.

Being a great Scrum Master is not the same as knowing Scrum well.

After almost 2 decades of practicing, teaching, and mentoring Agile Product Leaders, I've identified 100+ books that consistently help me develop the skills necessary to succeed in this space.

Out of these, I will share 9 books with you today.

Let’s get started.

Book #1 — Turn the Ship Around!

As a Scrum Master, you’ve probably seen it happen multiple times: the team hits a roadblock, and suddenly, everyone looks to you or the Product Owner for answers.

This is a classic example of the "leader-follower" model in action.

But there is a problem with this model.

It creates bottlenecks that slow decision-making when speed matters.

David Marquet’s book Turn the Ship Around offers a game-changing solution: push authority to the edges.

In this book, Marquet, a former submarine commander, shares how he transformed a struggling crew into a self-organizing, self-managing team by adopting what he calls the "Leader-Leader" model.

Why should you read this book?

It gives you 3 tools to help create self-organizing teams:

The Control Allocation Matrix: A framework for classifying decisions
The Technical Authority Ladder: A guide to empowering senior developers
The "I Intend To…" Protocol: To transform passive team members into proactive leaders.

For example:

Instead of: "Should I refactor the payment module?"
They say: "I intend to refactor the payment module because it will reduce technical debt and improve processing speed."

The difference?

The first approach seeks permission. The second demonstrates ownership and critical thinking.

If you want to build a self-sustaining, high-performing team, Turn the Ship Around! is your playbook.

Book #2 — Creative Problem Solving For Managers

What do you do when your team faces recurring blockers?

Missed deadlines, workflow inefficiencies, or technical roadblocks can stall progress, and as a Scrum Master, it’s your job to help the team navigate these challenges effectively.

This is where Tony Proctor's book, "Creative Problem Solving for Managers," becomes invaluable.

In this book, Tony introduces a structured model for problem-solving:

Clarify
Ideate
Develop
Implement

It’s an iterative framework for problem-solving that’s particularly useful in complex Agile environments.

He talks about several other techniques like:

The "Five Whys" for Groups
"Brainwriting" for Silent Idea Generation
etc.

This book taught me that sometimes, the best way to solve problems is to “change how we solve problems.”

This book is a whole new way of thinking about impediment resolution.

And trust me, once you start applying these techniques, you'll never look at team problems the same way again.

Book #3 — Leadership in War

This might seem like an unusual choice for Scrum Masters.

I mean, what could military leadership during wartime possibly teach us about leading agile teams?

A lot, actually. More than you might imagine.

This book is a masterclass in “adaptive leadership” through the lens of some of history's most crucial moments.

Let me explain why this book is pure gold for Scrum Masters...

It talks about the strategies used by Churchill and Eisenhower during war times.

Scrum Master Performance Tracker v1.0

Vibhor Chandel — Sun, 09 Feb 2025 08:15:45 GMT

Hey Friends 👋

As promised, here is the Scrum Master Performance Tracker v1.0, just as I discussed in the last post. With the help of this tool, you can:

record your manager’s expectations
map them to specific metrics
generate analytics for all your metrics, and
automatically create reports that you can share with your manager

This tool makes it super easy for you to prove your impact on your team’s productivity and helps you present it to your Manager in a language that makes sense to them.

No more struggling to quantify your contributions or scrambling to pull data before a review.

With this tracker, you’ll always have a clear, data-backed “story” (automatically generated for you) about how you’re driving Agility and continuous improvement within your team.

Important: This app's data is not stored in any external database. It is stored locally on your computer. I designed it to be lightweight, intuitive, and—most importantly—actually useful in your daily work as a Scrum Master.

How do you get access to this tool?

It is available for FREE to all the paid members of Winning Strategy. You can access the weblink using the community chat (linked below).

Get Scrum Master Performance Tracker

If you are new here: This newsletter shares insights gained from real-world experiences that I gathered working at Twitter, Amazon, and now as an Executive Product Coach at one of North America's largest banks. Plus, you get access to free productivity tools every month. If you’d like to become a paid member, see the benefits here, and feel free to use this expense template to ask your manager.

Connect With Me

As a Scrum Master - How Do You Prove Your Impact?

Vibhor Chandel — Thu, 06 Feb 2025 08:15:41 GMT

Subscribe now

A few years ago, I published this video on YouTube.

In it, I discussed this “idea” of measuring a Scrum Master’s performance.

I explained how a Scrum Master’s performance is subjective and can only be evaluated based on the expectations of those with whom the role interacts.

For example:

A Product Owner would evaluate a Scrum Master based on how well they facilitate backlog refinement sessions and help the Product Owner deliver value to stakeholders
A team member would evaluate a Scrum master based on how well they help the team remove impediments, protect the team from distractions, and enable an environment of psychological safety
A Manager would evaluate a Scrum master on team productivity and their impact on business agility and value delivery

This subjectivity makes it hard for Scrum Masters to answer the survival question:

"How do I prove my impact?"

If you’re a Scrum Master reading this, you’ve probably felt this uncertainty.

You know you’re doing meaningful work — coaching the team, facilitating meetings, driving improvement but when it comes to proving this to leadership, it feels intangible.

And when leadership starts asking for measurable outcomes, such as business metrics or other value indicators, you feel overwhelmed.

The truth is, articulating the impact of a Scrum Master’s work is challenging.

But… it’s not impossible.

You just need the right approach.

In this post, I will highlight that approach.

I will outline some steps you can begin taking right now to better prepare yourself for the year-end review. I’ll share a step-by-step framework to help you quantify your work in a way that’s both measurable and meaningful.

This framework will empower you to not only track your contribution throughout the year but also communicate it confidently during year-end reviews or when leadership asks,

“What have you done that’s made a difference?”

Sounds like a plan?

Let’s get started.

Introducing — Scrum Master Performance Tracker™

As a valued paid member of Winning Strategy, you will be able to access the Scrum Master Performance Tracker, which is being released this coming Sunday.

With the help of this tracker, you will be able to:

collect
quantify, and
present

your impact and the difference you made to your team’s performance every quarter. Plus, you’ll be able to do that in a language that resonates with your Manager.

Let’s see how the framework actually works…

Subscribe now

Step #1 — Collect the requirements

Requirements?

Yes!

As discussed above and in the YouTube video, your performance as a Scrum Master is largely subjective. It depends on what is “required” of you by the people you interact with. In other words, it depends on what other people “expect” from you and your role.

And here’s something I learned the hard way as a new SM.

These “expectations” differ from person to person.

Expectations are mirrors—what you see depends on who's holding them.

So the first thing we do is “collect” as many expectations as possible from the people who matter. These people may also differ based on your situation and context. But for the sake of this post, we will stick with the following roles:

Your Manager
Product Owner
Team Members (collective expectations)

Here’s how you will go about collecting these expectations.

1. Your Manager

Start by having a 1:1 conversation with your manager.

Ask them directly, “What does success look like for me by the end of this year?”

Managers often have specific business metrics or outcomes in mind.

Take notes.

Understand their priorities. If possible, ask follow-up questions to clarify how they will measure your success.

Make a list of these expectations. For example:

Predictable Delivery
Increased Productivity
Faster Time-to-Market
Improved Quality
Improved Customer Satisfaction
Cost Efficiency
etc.

Don’t worry about how these map out to your role yet. Just collect these expectations and make a list.

2. Product Owner

The Product Owner works closely with you, so their expectations usually revolve around the product and delivery.

In a 1:1, ask them the following questions:

Q1: “What would success look like from your perspective?”

Q2: “How can I help you deliver value more effectively?”

This might lead to feedback about supporting backlog refinement sessions, managing dependencies, or helping improve communication with stakeholders.

Make a list like the one below:

Better refinement sessions with fewer scope changes
More predictable sprint deliveries
Improved stakeholder communication
Better dependency management
Help in managing scope and expectations
Clearer progress visibility
etc.

3. Team Members (Collective Expectations)

Your team will have collective expectations of you as their Scrum Master.

You can ask for their expectations through:

1. Retrospectives: Dedicate part of a retrospective to ask, “What do you expect from me as your Scrum Master?”

Or you can send them…

2. Anonymous Surveys: If your team prefers anonymity, send them a short survey with open-ended questions like:

What do you expect from me as your Scrum Master to help you perform your best work?
What challenges do you think I should focus on helping the team with?
How can I improve how I facilitate sprint events?
What can I do to help improve team collaboration and communication?
How can I better support the team in achieving its goals?
What areas of our process do you think need more attention from me?
How can I help create a more positive and safe team environment?
Is there anything I’m currently doing that you find particularly helpful?
Is there anything I’m doing that you think I should do differently?

Your team’s expectations will include things like:

Help in removing impediments
Protection from unnecessary interruptions
Help with technical debt discussions
Better coordination with other teams
More time-efficient events
Support in conflict resolution
etc.

Here are a few suggestions while you collect these expectations:

Do not get defensive about expectations
Do not make immediate commitments
Do not make promises yet - just listen and note

Document everything in a simple spreadsheet or in the “Scrum Master Performance Tracker” coming this Sunday.

Consider this your performance backlog.

The items inside are your “requirements,” which you must deliver to prove your impact on the team.

7 Habits to Earn Your Manager’s Trust and Respect

Vibhor Chandel — Thu, 23 Jan 2025 08:16:03 GMT

Have you ever wondered what it takes to stand out at work?

Not just as someone who does the job but also as the person your manager instinctively trusts to take on the big responsibilities?

“Who can I trust to handle this?”

That’s the question every manager asks themselves when something important comes up — and the answer isn’t always the most obvious choice.

Early in my career, I struggled to be that person.

I worked hard, hit my deadlines, and thought that would be enough.

But the truth is, it wasn’t.

My manager trusted me to do my job, sure, but when it came to the bigger opportunities — the ones that really mattered — I wasn’t the first person they thought of.

That realization was a hard pill to swallow.

I wasn’t just looking for approval — I wanted to be indispensable.

I started paying attention to the “habits of the people” my manager trusted most and made it my mission to do the same.

Over time, I saw the shift happen.

If you’re not there yet — you’re about to learn how to change that.

In this post, I’ll share 7 habits to ensure your manager sees you as someone they want to rely on.

These habits will set you apart from everyone else in the room.

Let’s get started.

If you’re new, here’s what you missed in the last few weeks:

Habit #1 — Be the first face your manager sees in the morning

I noticed that people who earned that respect from their bosses were the first to come and last to leave the office. But let me be clear — they were not playing the overtime game.

They were playing the strategy game.

These people understood a simple truth:

Being early means you're already in the flow when others are just starting their day.

When your manager walks in, you're not rushing through the door or frantically logging into your computer — you're already making progress.

Being the first face your manager sees when they walk into the office immediately conveys one message:

YOU ARE INVESTED!

Now, don’t get me wrong.

I don’t mean you burn yourself out or work yourself to exhaustion. I mean, you become intentional with your time.

I learned to come in 30 minutes before my usual start time. That quiet morning period became my secret weapon. I used it to:

review the day's priorities
clean up my inbox
prepare questions for upcoming meetings
plan any important conversations

The result?

When my manager arrived, I could greet them with updates rather than questions. I wasn't just present — I was prepared.

Keep in mind that consistency is key here.

It's better to arrive at 8:30 a.m. every day than to show up at 7 a.m. three times and then slip back to rushing in at 9 a.m. Your manager needs to know they can count on you being there.

This habit isn't about showing off.

NO!

It's about creating a reputation for reliability.

When your manager knows you're always there, ready to tackle whatever comes up, trust follows naturally.

Additional Reading:

Habit #2 — Be self-directed

Here's something I learned the hard way:

Every time you ask your manager, "What should I do next?" you're adding to their mental load.

Every time you run to them with a problem before trying to solve it yourself, you're showing them one thing: You're dependent.

And dependence won’t make your manager say, “I can rely on this guy.”

Think about it.

The people your manager trusts aren't the ones constantly asking for direction. They're the ones who come with solutions, not just problems.

They're the ones who say: "I noticed this issue, here's what I think we should do, and here's why."

Instead of: "I found a problem – what should I do?"

This was a game-changer for me.

I started treating every challenge as an opportunity to show initiative. Before going to my manager, I'd check myself for self-management:

have I tried to solve this myself?
have I researched potential solutions?
can I present options instead of questions?
do I have a recommended approach?

I would then use the Pyramid Principle to present the Problem + Solution to the manager.

Here's the truth:

Your manager WANTS you to think independently. They WANT you to take ownership.

But remember…

Being self-directed is not about keeping problems to yourself. It's about using your good judgment to decide when to handle things independently and when to invite others to join in the conversation.

Keep your manager informed, not consulted.

Instead of asking, "Should I do X?" ask, "I'm planning to do X because [for this reason]. Let me know if you see any concerns."

See the difference?

One approach dumps the decision in their lap.

The other shows you can think for yourself while keeping them in the loop.

That's how trust is built.

Not by being a robot that needs programming but by being a partner who can think critically and act decisively.

Your manager will notice.

And more importantly?

They'll remember.

Enterprise Agile Coach Interview Preparation

Vibhor Chandel — Sun, 01 Dec 2024 08:04:51 GMT

👋 Hello, I’m Vibhor, and welcome to the 🔒 subscriber-only edition 🔒 of my weekly Training Series powered by Winning Strategy. Every week, I answer two reader questions and publish 2 posts about Agile Products, Role-Based Skills, and anything else that you need answered about your Career Growth. You can send me your questions here.

Subscribe now

On to this week’s question.

Q: I have been an Agile Coach for 5 years and am preparing to apply for the position of Enterprise Agile Coach for a large financial firm. The firm is undergoing Agile Transformation and is hiring Agile Coaches to help with that initiative. My last interview will be with the company's CIO, and I was hoping you could give me some pointers regarding what to expect and how to approach the interview.

Thank you for the question.

First of all, congratulations on the move.

I have a reference document that I have prepared for such interviews, and I refer to it whenever I am asked to plan interviews for Agile Transformation coaches. However, that document also has other unrelated stuff, so I will only share the part relevant to your question here.

When interviewing with executives, remember they will not judge you on Agile. They are not interested in Agile's internal workings.

They are interested in the overall impact of Agile Transformation on the rest of the organization.

They want to understand:

How will this transformation affect their bottom line?
What are the risks involved?
How will it impact their existing processes and systems?
What is the timeline for seeing tangible results?
How will it affect their competitive position in the market?

And!

How will you help with all of that?

They are looking for someone who can speak their language – the language of:

business outcomes,
risk management, and
strategic advantage

Your role in the interview is to demonstrate that you understand their perspective and can translate Agile Principles into Business Value.

For them, you're not just an Agile Coach!

You're a “business partner” who will help with Agile Transformation.

Alright!

The document explains and answers 14 questions below:

Why do we need to explore Agile?
Why are there so many definitions of Agile? What is the right one?
Why is failing fast such a great thing?
What is the impact of Agile on quality?
What has been the regulatory experience for Agile Shops? What is the regulators’ POV vs the enterprise's POV?
We heard there is no need for business cases for Agile — is this true? If there is no longer the traditional business case, what’s the replacement?

10 Mistakes In Your First 30 Days - Agile Coach

Vibhor Chandel — Thu, 28 Nov 2024 08:15:51 GMT

Winning Strategy: Career Track

From Servant Leader to an Agile Delivery Lead

Got an urgent question?

My Advice for Scrum Masters to Get a New Role Faster

Got an urgent question?

As a Scrum Master, how do I make sure my impact is seen, heard, and valued?

Got an urgent question?

Read this before starting with a new team as a Scrum Master

Got an urgent question?

#1 Be confident

#2 Get introduced

#3 Learn about their expectations

Remember: Expectations of your manager and your team always take priority.

#4 Find out your team’s current state and process

You can find this information in 2 steps:

#5 Draw a stakeholder map

Primary Stakeholders:

Secondary Stakeholders:

#6 Understand the product

#7 Find your champion

The Journey Forward

Show your support

Connect With Me

11 Rules of Thumb for When and How to Escalate Any Issue at Work

If you’re new, here’s what you missed

Got an urgent question?

#1 Tie the issue to a Business Risk first

Here’s a rule of thumb:

The test is simple:

#2 Exhaust team level options before going up

#3 Do a written, time boxed agreement

#4 Look for multiple occurrences, not one-offs

Here’s a simple rule of thumb:

Show your support

#5 Collect 2 metrics, not 20

#6 Escalate with an ally

#7 Offer a solution, not just a complaint

#8 Keep the message ≤ 3 minutes

#9 Don’t use Agile jargon

#10 Maintain Psychological Safety

#11 Escalate up, then let go

The Journey Forward

Further Reading

Connect With Me

My morning routine that boosts my presence as a team coach

How to speak the language of AI?

Get the Substack App (Recommended)

What is Prompt Engineering?

Generative AI vs Agentic AI

What is Generative AI?

Mistakes I Didn't Know I Was Making As a Growing Scrum Master

Related Posts

Mistake #1: Not Reaching Out to Executives

How I Realized it?

What Was Holding Me Back

How I Fixed It

Outcome

From me to you

Mistake #2: Focusing Only on Coaching

How I Realized the Mistake?

Mistake #3: Stopping My Own Learning

How I Realized the Mistake?

What Was Holding Me Back?

How I Fixed It

Outcome

9 Proven Mental Models for Scrum Masters

If you’re new, here’s what you missed in the last few weeks

What are Mental Models?

MeMod #1: The Serenity Principle

MeMod #2: The 10-10-10 Rule

How it works:

How it helps:

Example:

Let me share a story.

MeMod #3: Anti-Fragility

How it works:

How it helps:

Example:

MeMod #4: Hanlon’s Razor

What it says: