Most Scrum Masters believe their job is to remove impediments. It says so right there in the Scrum Guide. It’s the first thing they teach you.

And…

It’s the single biggest reason your team can’t remove impediments… Without YOU!

When teams default to handing you every impediment, two things happen:

1. you burn out, and

2. the team learns helplessness

Agility at scale requires autonomous teams that can navigate their own roadblocks. If your team stops moving the moment you are not around, you are basically facilitating dependency.

To help your team resolve impediments without relying on you, you have to intentionally change your stance from fixing to enabling.

In this post, I want to show you

1. why teams become dependent on their Scrum Masters,

2. what’s happening in their brains when this happens, and

3. a four-part behavioural model for rewiring the habit

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

On Thursday, March 5th, 2026, we discussed the “Bad Apple” effect and why relying solely on 1:1 conversations to address difficult team members rarely works.

We learned that Scrum teams are cooperative machines, and when someone defects (misses commitments, ignores process or team norms, etc.), you need a systemic response.

Today’s recipe, which is in the form of a workbook, will help you build that system.

The Accountability Workbook walks you through the exact steps to diagnose the behavior, fix the team environment, hold the individual accountable, and, if necessary, escalate with a proper paper trail.

You can download the recipe below.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

He planted a bad actor in small working groups, sometimes a slacker, sometimes a jerk and measured the group's performance.

It turned out that one person can reduce a group's performance by 30 to 40 percent.

The bad apple didn’t do any direct sabotage.

Instead, just their mere presence was enough to indirectly change the team's emotional and behavioural equilibrium. The other members began mirroring that negativity. For example, they too started bickering, disengaging, and checking out.

The dysfunction spread through the team, affecting everyone.

However, a few groups were able to resist this.

The groups that resisted the effect were the ones with a member who actively managed the dynamic, who redirected conversations, defused tension, and reestablished norms in real time.

In other words, the presence of the bad apple was a constant. Whether it destroyed the team… depended on the system around it.

Today, I want to talk about dealing with this bad apple step by step.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

The Coordination Problem

The thing about Scrum teams… or any small, cross-functional team trying to ship work in short cycles is that…

They're COOPERATION machines.

This kind of model depends on a set of unspoken agreements:

For example:

• I'll do my part, you'll do yours,

• We'll be transparent about progress,

• We'll hold a shared quality bar, and

• When something goes wrong, we'll adapt together rather than pointing fingers

But…

If you look closely at it, you will find that it is ACTUALLY an Iterated Prisoner's Dilemma.

Note: The Iterated Prisoner’s Dilemma is a very interesting concept. Check it out at the link provided.

Every Sprint is a new round of the game. Every Sprint commitment is a signal of cooperation. And the whole thing works beautifully... right up until one player starts defecting in one of the following ways:

• they over-commit and under-deliver

• they bypass the Definition of Done

• they let work sit in progress for days without raising a flag and then dump the risk on the team at the end of the Sprint

• or maybe they just refuse to engage with the process at all

It doesn't matter which defection it is. What matters is the second-order effect.

Here’s what it means:

When one person consistently defects in an iterated game (like Sprints), one of two things happens. Either the other players start defecting too, i.e. they stop going the extra mile, they protect their own work, they quietly disengage, OR they start over-cooperating to compensate, absorbing the defector's risk, Sprint after Sprint, until THEY BURN OUT AND LEAVE.

Both outcomes eventually destroy the team.

So what should you do?

Should you have a 1:1 meeting with them?

Why "talking to them 1:1" is necessary but not sufficient

Every article on dealing with difficult team members eventually comes to the same advice: have an honest conversation… 1:1.

And look, that’s correct.

You absolutely need to have the 1:1 conversation. It is “necessary.”

But…

It is not sufficient.

Just like building a great product is “necessary” for building a great company, but it is not “sufficient.” (You also need distribution, timing, capital, talent, and about forty other things.)

Now…

Here’s how it generally goes:

• you notice the problem…

• … you agonize about it for three weeks,

• … you finally have The 1:1 Conversation,

• … it goes reasonably well,

• … you both agree to do better, and then...

• … absolutely nothing changes

Two Sprints later, you're back where you started, except now you're also annoyed that The 1:1 Conversation didn't work.

The conversation didn't work because “conversations” ARE NOT systems.

A conversation is a point-in-time event. And a system is a persistent structure that shapes behavior continuously. You need both, but if you only have the conversation without changing the system, you're basically hoping that a single input will permanently alter someone's behavior.

That's not how people work. That's not how anything works.

So here's what I want to do.

I want to walk you through the full stack of interventions, from diagnosis to system design to escalation, and show you how each layer builds on the previous one.

We will build a “team level” infrastructure of accountability.

This will be followed by the Weekly Recipe on the coming Sunday, which you can apply directly to your team.

Read more

If we want to build the right product, we need to cultivate a sustainable habit of clarification.

We want a Q&A system that can help us build a shared understanding.

Today, I’m sharing this PO Q&A System.

As always, this system has been tested and proven by many teams I have worked with previously. Adopting it will help you and your team in establishing consistent decision-making.

Here is what this system covers:

• The Intake process: How to capture questions

• The Questioning Format: To close the gap between a question and a response

• The SLA: Clear time-bound expectations

• A visible, documented outcome

• A triage + escalation path

• The Anti-Pattern: What didn’t work for us

Let’s get started.

Note: The link to the archive containing all past templates will soon be emailed to all yearly paid subscribers.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Under Pressure.

We discussed why, during high-pressure situations, nobody pulls up the agreement. Why teams usually revert to the original manifesto?

Things like:

• urgency over outcomes

• hierarchy over collaboration

• “whoever shouts loudest” over decision making

• heroics over sustainable delivery

• Slack priorities over prioritization

And because nothing officially breaks, i.e. no one is specifically “against” the agreement, the routine repeats.

Read Part-1 here if you haven’t already.

In this post, which is Part-2 of the series, we discuss the solution. A recipe that you can apply to your dysfunctional Working Agreement.

Let’s get started.

BTW, speaking of “recipes,” I have an important announcement to make.

📣 Announcement

Starting next week, I am bringing a new format to these newsletters to make them more practical and usable in the trenches.

Introducing Weekly Recipes (launching Thu 26 Feb + Sun 1 Mar).

Every week on Sunday, you’ll get a tested, ready-to-use RECIPE that you can apply immediately to your team environment as an Agile Delivery Lead, Scrum Master, or Product Owner.

What’s a recipe?

A recipe is a short, repeatable “how-to” you can run in your work situation, with a clear structure, suggested wording, and key inputs, so you can adapt it to your context without starting from scratch.

It will be a combination of: template + facilitation guidelines + what didn’t work (for us) + metrics, with recommendations on:

• When to use it (and when not to)

• What you need before you start

• A clear, straightforward (but strategic) approach

These recipes are the wonderful result of collaboration between the Product Experts I've had the pleasure of working with in the past and the talented individuals I am currently lucky enough to work with.

How will it work (every week)

• Thursday: Post with insight + actionable takeaway

• Sunday: the Weekly Recipe

What paid members get:

• Monthly + Yearly subscribers: The complete recipe (including the full template/script)

• Yearly subscribers: Access to the growing Recipe Library with the Archive of all the past templates that have already been published on Winning Strategy

I’m excited to ship these because they’re the exact tools I wish I had while working with teams under pressure. More on this next Thursday.

Back to How Mature Agile Teams Handle Pressure? (Part-2)

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Working Agreement to Team Protocols Workshop

The purpose of this workshop is to document 3–5 rules written as If → Then behaviors. These will be embedded into Scrum events, with owners, escalation paths, and consequences.

To start…

Ask everyone (PO, SM, Devs) to submit answers (scenarios) to the following two questions:

1. “What’s a recent moment of pressure where we didn’t act like our working agreement?”

2. “What’s the most common ‘problem’ in our team: priority, scope, quality, decision-making, interruptions, stakeholder bypassing, or something else?”

You’ll bring these answers (scenarios) into the workshop below.

Read more

THEY ARE USELESS.

Why?

Because 99% of teams build them wrong. They write them like mission statements full of aspirational garbage that sounds great when they are first written, but means nothing when things go sideways.

Every team I worked with had one. Most teams ignored theirs. And the pattern of ignoring it right when they needed it most revealed the gap that answers how groups actually make decisions under pressure.

This post explains the reasons behind that gap.

It’s a two-part series.

This is Part 1 of “How Mature Agile Teams Handle Pressure?”

Part-1: Why your working agreement is useless under pressure? ← this post

Part-2: How to transform a working agreement into an operating protocol?

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Reason#1: Your Agreement Is Full of Values, Not Instructions

Yep.

Your Working Agreement sounds like the Agile Manifesto:

"We communicate openly." "We respect each other." "We assume positive intent."

Cool. Now what?

These are values. They tell you what to care about. They don’t tell you what to do. And when you’re in the middle of a production incident or a stakeholder is screaming about a Friday deadline, your brain doesn’t need philosophy. It needs a decision tree.

Something that can help your team make decisions like:

“Who makes the call right now?”

“What do we do when we disagree?”

“What happens when someone goes around the process?”

“How do we stop this from turning into a two-hour argument?”

If your agreement doesn’t answer these questions specifically, it won't be used. Period.

Your brain can’t execute “be respectful” under cognitive load. It needs: “When we disagree on priority, the PO makes the final call. If the team thinks it’s a technical risk issue, we escalate to the CTO within 24 hours.”

That’s a protocol, and it is SUPER usable.

Read more

Not the 1960 Sinatra version, the 2001 Soderbergh version, the one where George Clooney assembles a team of eleven specialists to rob three Las Vegas casinos simultaneously.

Here’s what’s special about that team.

Every single person on the team is expertly good at their specific thing. Basher is the explosives guy. Livingston handles surveillance. Linus is the pickpocket. They each operate with near total autonomy within their domain. Nobody tells Basher how to rig a charge, or gives Livingston direction on hacking cameras.

They all have “autonomy,” but at the same time, they're all “committed” to ONE SINGLE PLAN.

One shared commitment and one timeline. If Basher misuses his freedom and blows the vault thirty seconds early, it doesn't matter how brilliant his (or other people’s) technique is. The whole thing collapses.

Danny Ocean (their lead) is not commanding or controlling anyone. He ensures that these eleven autonomous specialists stay aligned on a single shared outcome. He sets the target and removes obstacles. And then he gets out of the way.

Now replace this heist with "sprint delivery," replace the eleven specialists with your dev team, and replace Danny Ocean with YOU, the Delivery Lead (or the Scrum Master).

The job is almost identical with one tiny difference.

How is Danny Ocean able to make individual autonomy and team commitment coexist so easily, and why do we find it so difficult?

Let me explain why and, more importantly, what the research says about how to actually do it.

Let’s dig in.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Why autonomy matters

I know a ton of leaders who treat autonomy as a perk, something you grant to senior engineers who've "earned it." The research says something very different.

Psychologists Edward Deci and Richard Ryan spent decades developing Self-Determination Theory (SDT), one of the most validated motivational frameworks in psychology. According to their findings, humans have three core psychological needs that drive intrinsic motivation.

• Autonomy: the feeling that you have genuine choice and agency over your work

• Competence: the feeling that you’re effective, growing, and being challenged appropriately

• Relatedness: the feeling that you belong and your contributions matter to people you care about

When any of these is suppressed, people move from intrinsic motivation ("I care about this") to extrinsic motivation ("I'm doing this because I have to"). The work might still get done. But creativity, persistence, and quality all decline.

A 2017 meta-analysis by Van den Broeck et al., covering 99,000+ workers, found that satisfaction of these three needs was significantly linked to commitment and performance, with “autonomy” as the strongest predictor.

Why does this matter to you?

It matters because your job (as a Scrum Master or Delivery Lead) is to create conditions where all three needs are met simultaneously.

Autonomy without relatedness → fragmented team.
Autonomy without competence → struggling team
Relatedness without autonomy → comfortable and stagnant team.

You need the full triangle.

But how?

First: Build Psychological Safety

I am pretty sure you already know this, but here’s a recap.

In the year 2012, Google ran one of the largest studies on team effectiveness ever conducted.

Project Aristotle.

180+ teams. The variables measured were composition, seniority, intelligence, co-location, and workload.

What do you think was the most important factor for team effectiveness?

It was Psychological safety!

Psychological safety is the shared belief that the team is safe for interpersonal risk-taking.

This also aligns with Harvard professor Amy Edmondson’s research (she coined the term in 1999).

Her findings across hospitals, factories, and tech companies: Teams that openly discussed mistakes outperformed teams that hid them. Even when the "hiding" teams had more experienced members.

Here’s why this matters for Self-Determination Theory (SDT:

Psychological safety supports all three SDT needs at once.

→ Autonomy: “I can take risks.”
→ Competence: “I can admit what I don’t know.”
→ Relatedness: “These people have my back.”

So…

Before we can worry about autonomy, we should ask ourselves this one question:

“Does my team feel safe enough to disagree, flag risks, and admit mistakes?”

If the answer is no, fixing that is job #1.

Everything else builds on top of that.

Second: Improve Visibility

There’s a known phenomenon in psychology called the Ringelmann Effect. In the 1910s, a French researcher found that as group size increases, individual effort decreases.

The reason, it turned out, was that when individual contributions become less visible, the psychological incentive to give full effort weakens. Researchers call this Social Loafing.

What’s the fix?

Visibility!

Here’s what doesn’t work for visibility:

Jira issue updates. Time tracking. "What did you do today?" standups. Code commit metrics.

All of this is the wrong frame.

It's trying to measure inputs when what matters is outputs/outcomes. It's trying to solve an information problem with an enforcement problem.

Here’s what works for visibility:

Shared team state.

The best implementation I’ve seen is simple.

One big screen in the team space (or a pinned Slack channel for remote teams) that shows:

1. Days left in sprint

2. Committed work completion percentage

3. Current trajectory vs. goal

4. Blockers count

That’s it. Four numbers. Updated automatically every hour. It shows where the team is relative to where the team said they'd be.

Here's what happens when you implement this:

The team self-corrects.

When sprint goal is behind? Someone says, “I can defer my discretionary work and pair on the sprint goal work.”

When the sprint goal ahead of track? Someone says, “I’m going to pull that tech debt item we’ve been wanting to fix.”

The accountability becomes collective.

And it’s immediate.

Third: Replace consensus with consent

This is a small change, but it saves a huge amount of time.

Most teams default to one of two decision-making modes:

1. consensus (everyone must agree)

2. authority (the lead decides)

Both have problems.

Consensus is slow and produces watered-down compromises. Authority is fast but kills engagement.

There's a better model, drawn from sociocratic governance:

Consent-based decision-making.

It’s the middle ground.

Consent requires the absence of a reasoned, paramount objection.

Anyone can raise an objection, and objections are taken seriously. But "I would have done it differently" isn't an objection.

Research on procedural justice consistently shows that people accept outcomes they would prefer not to have when they believe the process was fair. Being heard matters more than winning.

Here’s how to do it:

After every discussion where you need to make a decision, ask: "Can everyone live with this for the next two weeks, even if it's not your first choice?" If someone can't, they explain why, and the proposal is modified accordingly. If everyone can, you move.

How much freedom does your team actually need?

If you’ve read this far, you might be thinking the message is simple: give people more autonomy, more ownership, more space and good things follow.

That's half right. And the other half is where many delivery leads get into trouble.

Autonomy is a judgment call. The amount of freedom your team needs depends on what’s actually happening right now. Some sprints need a lighter touch. Some need a firmer hand. The skill isn’t in picking one approach. You must know when to move between them.

There are four variables to help you decide when and how much to move.

1. Team Maturity

A team that formed two months ago is still figuring out:

• how to communicate,

• who does what, and

• how to handle disagreements

They need clearer roles, shorter feedback loops, and more frequent check-ins.

A team that's been shipping together for two years already has those things figured out.

They need space to do their thing.

Treat them accordingly.

Tuckman’s model (forming → storming → norming → performing) is a cliché because it’s true.

Don’t give a forming team the autonomy of a performing team.

2. Problem familiarity

If they've built something similar before in a domain they know well, step back and let them do their stuff.

But if the requirements are unclear, the technology is unfamiliar, or no one is really sure what "done" looks like, then shrink the feedback loop.

Check in more.

Small misunderstandings in unfamiliar territory compound quickly, and catching them early is the whole point of tighter feedback loops.

3. Stakes

Not all work carries the same risk.

• Low-risk experiment? Let them explore freely

• High-risk production release? Stay closer, coordinate tighter

That's just responsible behavior, not controlling.

4. Trust level

Trust is the variable that amplifies or undermines everything else.

When trust is high, people flag risks early, ask for help without hesitation, and hold each other accountable without being asked. Here you can lean heavily into autonomy.

When trust is low, maybe someone new just joined, maybe the last sprint went sideways, maybe there's an unresolved tension, add more visibility and more structure.

Here’s how to implement these 4 variables:

Rate each of these four variables in your team as low, medium, or high.

Read the results:

Fill this out at the start of every sprint. Keep a running log.

After a few months, you'll spot patterns like which variables tend to dip before a rough sprint, and you'll start making adjustments before problems surface instead of after.

The Progress Principle

Everything above works as a system and not as a collection of disconnected activities.

Here’s why.

Teresa Amabile and Steven Kramer collected nearly 12,000 daily diary entries from 238 professionals across 26 project teams.

According to their findings, which were published as The Progress Principle:

The single most important factor in sustaining motivation and engagement was making progress on meaningful work.

Not big wins.

Small. Daily. Visible. Progress.

This is what creates the flywheel:

Team builds the plan → executes with autonomy → sees visible progress → delivers on the commitment → that builds trust → trust earns more autonomy → autonomy deepens ownership → ownership strengthens the next commitment → the flywheel keeps rolling.

But… be cautious, as it can spin both ways.

One commitment broken without acknowledgment. One decision made unilaterally that should’ve been made by the team. One person who flags a risk and is blamed.

These things can reverse the flywheel.

Takeaway…

Don’t try to balance autonomy and commitment.

Build a structure that produces autonomy and commitments that people choose to keep.

That’s it.

That’s the whole game in Ocean’s Eleven.

Show your support

Every post on Winning Strategy takes a few 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 advise 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.

Further Reading

1. What Can You do to Create Self-Organizing Teams?

2. How to Navigate a Team that Does Not Involve You as an Agile Coach?

3. Role of Sponsors, Stakeholders and Managers in Agile

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

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.

Leave a comment

When I was a Scrum Master, my biggest headache was the senior developer who rolled his eyes every time I said "Sprint Goal."

I spent my days protecting the very people who wanted me out.

It's silly… really!

Agile Delivery Leads don’t deal with all this, but that doesn’t mean their lives are free of problematic personalities.

They (often) get steamrolled by VPs who don’t care about "story points" or "team feelings.” They just want to know why we are not done yet.

The ecosystem you’re in is complex, and as a Delivery Lead, you’re responsible for managing delivery across this complexity.

For you, the "difficult people" are not resistant team members. They are executives, gatekeepers, and ghosts from the PMO.

In this post, I will show you the reality of the 7 difficult personalities I encountered and how I handled them without losing my mind.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

#1: Manager who needs control

Why are they “difficult”?

They’re NOT “against Agile.” No! They (usually) love Agility.

The problem with a control-oriented manager is that they simply have a “high” need for Certainty.

They’re usually accountable for outcomes, and if they don’t trust the delivery system to hold up under pressure, they step in and try to manage the work directly.

You’ll notice it when they keep telling the team how to do the work instead of aligning on what outcomes are needed. They sometimes even override priorities, interrupt sprints, and assign work directly to individuals. They also sometimes hold status meetings for compliance checks.

What I’ve found works best with them is not fighting them on “control vs autonomy.”

No. You’ll burn yourself out if you do that.

Agree on a few things with them:

• clear guardrails that give them confidence in the delivery (eg, incident SLAs, escalation thresholds, reporting cadence, etc.)

• a predictable visibility cadence (eg, weekly delivery review, dependency view, risk log, forecast updates)

Also, make decision-making clear, i.e. who sets priorities, who decides on implementation, and under what conditions work can be interrupted.

Once they can see that you’re delivering reliably and consistently, they usually stop grabbing the steering wheel.

#2: HiPPO Stakeholder

HiPPOs like to be the decision makers. And they don’t trust data, experiments, the way you do.

You will hear them saying,

“I don’t care what research says. Customers want this.”

You can’t fight their authority, so that’s out of the question.

The only way out is to make them feel safe to be data-informed.

When I’m working with a HiPPO, I bring options with clear tradeoffs so it doesn’t feel like I’m challenging their authority.

For example,

Let’s say your HiPPO says, “We need Feature X. Customers want this.”

I won’t debate that.

I’ll respond by offering a list of options like:

• Option A (fast, risky): Build the full feature now to hit the date, with limited validation and a higher chance we’ll need to rework it

• Option B (slower, safer): Spend time validating first, then build. This will have lower rework risk, but we accept a later delivery

• Option C (MVP): Deliver the smallest usable version to test the outcome quickly, then decide whether to scale it up or stop

Then propose an “executive-friendly” experiment:

“Let’s run a 2-week experiment. We’ll ship a thin slice to a small segment and agree up front what ‘worked’ looks like.”

Timebox: 2 weeks

Success metrics (agreed with them):

• At least +10% increase in the target conversion step

• No more than +2% increase in support tickets related to this

Put it in a decision log and email it to them. For example:

Decision: Proceed with Option C (thin slice) of Feature X for a 2-week experiment to a limited audience.

Assumptions: Customers want Feature X enough that it will improve the target conversion step without increasing support load.

Expected impact: +10% on the target conversion step; support tickets stay within +2%.

Review date: End of week 2 (based on the agreed metrics), show “did the assumptions hold or not?”

At the end of week 2… review:

“Conversion moved +3% (below target).

Support tickets went +4% (above threshold).

Based on what we agreed, this didn’t meet the bar. Do you want to adjust the approach or stop?”

This helps them stay in charge of the decision while slowly learning to trust evidence over instinct because it was their experiment, their options, and their success criteria all along.

#3: Product Owner who wants Everything

For them, “Everything Is Priority #1.”

It’s not their fault, though!

They’re usually hammered by multiple stakeholders, all shouting that their thing is urgent. For them, prioritization may mean saying “no” to important people, which they want to avoid… at any cost!

As a result, they:

• Bloat and constantly reshuffle backlogs

• Have no clear product goal

• Want the team to “keep delivering”

What I’ve found works with them is:

1) Bringing the conversation back to capacity and tradeoffs. Use capacity as a forcing function:

“We’ve got roughly XXX engineer-days (or XX points) this sprint. What outcome will realistically fit in?”

2) You can also reinforce priority. If something is moving up, something else must move down.

3) I also try to shift their focus to measurable outcomes, such as conversions or cost reduction, and not just “features shipped.”

This gently pulls them out of “everything is urgent” mode into a shared picture of what really matters “now.”

#4: Stakeholder who wants to Avoid Risks

These are worse than a HiPPO.

You’ll find this person difficult because they might disagree but not feel safe saying it out loud.

So you get that frustrating pattern where a meeting ends in “agreement,” and then… nothing happens.

They don’t respond, approvals don’t happen, decisions get quietly reopened weeks later, and you find out they’ve escalated sideways to someone else to slow things down.

What I’ve found works is:

1) To take the heat out of the public forum and surface the real concern privately in a 1:1. A short 1:1 is often where you finally hear what’s going on. It may be risk, reputation, workload, loss of control, or even competing priorities.

2) Asking for clear consent so no one is operating on a vague “sure.”

For example:

“Are you a yes, a no, or a yes-with-conditions?”

If it’s conditional, turn it into something concrete: “What specifically would make this easy for you to support?”

Then document and confirm the decision, the owner, and the date in short written follow-ups, so there’s less room for misinterpretation later.

This turns vague, silent resistance into clear, owned commitments so we’re no longer guessing where things stand, and they can say “yes” (or “not yet”) without feeling exposed.

#5: Resource Controller

Resource controllers are accountable for utilization and staffing. You’re accountable for delivery and outcomes.

So your incentives… collide.

Have you seen instances where people are pulled into multiple initiatives, teams are frequently reshuffled, and key skills are temporarily 'borrowed,' leading to hidden delays?

Yep… resource controllers are the ones responsible.

When I’m working with a resource manager, I don’t argue.

I work strategically:

• I quantify the cost of context switching using impacts on lead times and missed dates

• II negotiate for “somewhat” stable teams with explicit allocation because even a 70/30 split is better than “everyone everywhere.”

• I also create a simple dependency/capacity map so the tradeoffs are visible at a leadership level

• And if we absolutely can’t have a skill full-time and we really do need to “borrow” someone, I propose a clear loan agreement with duration, purpose, expected outcomes, and a return date

For example:

“Yes, we want to borrow Sam. Let’s make the agreement clear so we don’t accidentally break the team’s flow. Sam joins our team for 2 weeks to unblock the payment integration. The expected outcome is a working integration in staging, plus a short handover note so the team can support it. Sam is back with you on Monday, the 15th. If we’re not on track by the end of week 1, you and I can decide whether we extend or de-scope.”

This turns the tug-of-war over “resources” into a visible, time-bound agreement that can be renegotiated… if needed.

#6: Compliance Gatekeeper

This person says “no” by default.

They’re incentivized to prevent bad outcomes, not to enable good ones, and they may be burned by past failures.

Take Security or Legal, for example. They usually get pulled in too late.

So there are late approvals, heavy documentation, etc., because they want to tick every checkbox in the compliance checklist.

When I’m working with a risk/compliance gatekeeper:

1) I bring them in early with a clear role: “Help us design the safe path.” They help the team shape the approach rather than gatekeeping at the end

2) I also encourage the team toward automated controls. Things like policy-as-code and pipeline checks with automated evidence so compliance isn’t manual and it is quick.

For example:

“Instead of a release checklist where someone manually confirms security items, I ask the team to turn those items into pipeline gates. For example, every pull request automatically runs dependency scanning and a vulnerability check. If it finds a critical issue, the build fails, and we fix it before merging. When it passes, the pipeline automatically stores the scan report and approver record, so the ‘evidence’ is generated as part of delivery. Not chased at the end.”

3) Also, because they usually default to “no,” I ask them for a conditional “yes.” Conditional yes works in most cases.

Example:

I ask, “Under what conditions would this be approved?”

And they might respond with conditions like:

• “If customer data is encrypted”

• “If access is limited to specific roles and we have an audit trail”

• “If we run a security scan and fix any critical findings”

• “If we have a rollback plan and monitoring in place”

The team reflects on these conditions and prepares a deliverable checklist.

“So if we implement…

• encryption,

• role-based access, audit logging,

• run the scan and clear criticals, and

• add rollback + monitoring,

… you’ll approve? “

So instead of racing to satisfy a mysterious checklist at the end, the team builds their conditions into the work from the start.

This earns them a predictable “yes.”

#7: Sponsor who is Always Absent

Disengaged Sponsors want results but won’t show up. They hold the authority you need for decisions, but they’re… ABSENT.

So… decisions are delayed. The team ends up guessing. And when you try to escalate, it goes nowhere.

When I’m dealing with a disengaged sponsor, I stop requesting long meetings (that they won’t attend anyway). I ask for short, focused slots where they can make a few specific calls that unblock delivery.

Example:

“Can I get 15 minutes with you tomorrow? I need three decisions to unblock the team:

1. Decision 1: Do we go with Option A or Option B for the release approach?

2. Decision 2: Are we prioritizing X over Y this sprint?

3. Decision 3…

Look, I get it.

They are busy, and this makes it easier for them to do their job as a sponsor. I get the decisions I need, and they get progress without feeling dragged into endless meetings.

Bottomline…

Here’s a suggestion.

As an Agile Delivery Lead, it's most helpful to remember to check the system first, rather than jumping to conclusions about individuals. This way, you approach challenges with a more collaborative mindset.

When someone feels “difficult,” run a quick diagnostic:

• Is their behaviour rational given their incentives?

• Do they have a different definition of success?

• Are we asking them to take risks without visibility?

• Is there an unspoken fear (career risk, audit risk, reputational risk)?

When you fix those conditions, many “difficult people” stop being difficult.

Also… don’t wait until there’s a problem.

Build alliances early through 1:1s with key stakeholders and by delivering small wins that matter to THEM. 

As a Scrum Masters you asked, “How do I coach the team better so they can succeed?”

As an Agile Delivery Lead, you ask, “How do I make the organization better for teams to succeed in?”

Also…

When you look at it this way, you realize that your hardest “people” are usually the ones closest to power, budgets, approvals, and competing priorities.

And that’s exactly where your leverage lies.

Show your support

Every post on Winning Strategy takes a few 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 advise 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.

Further Reading

1. 13 Techniques to Handle Difficult Situations During Meetings with Ease

2. The Irony of Scrum Master Role

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

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

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.

Leave a comment

“How do I get my team to care as much as I do?”

The team is not bad. Work gets done.

But:

You feel like you’re constantly nudging them. Team memebrs wait for direction instead of taking initiative. You feel a spike in their energy around releases, but it drops quickly afterward. And when things change (as they always do), you see motivation leaking out of the room.

You probably think your team has a morale problem.

You even wonder if you were hired in the wrong team. You assume your team has zero passion.

But…

What if I told you that your team is NOT the problem?

What if I told you that the reason they are stalling has nothing to do with their work and everything to do with the barrier that YOU might be accidentally creating every single day?

There is a hidden killer of productivity on software teams.

What’s surprising?

You know about it, yet YOU have been ignoring it.

Welcome to Winning Strategy 2026 🎉

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

When you join a new team as a Scrum Master, the “pressure” of “implementing Scrum” is high.

“I must justify my presence by showing how knowledgeable I am in Scrum.”

That’s the thought in most SMs' minds.

But…in reality (as experience has shown) your first 30 days shouldn’t be spent worrying about “implementing Scrum”… at all.

This crucial time should be spent strategizing how to build TRUST and ALIGNMENT.

On your first day with a new team, they’re thinking: “Is this person going to make my life easier… or harder?”

And if you don’t bridge the TRUST and ALIGNMENT gap faster, the journey may be harder.

In today’s post, I’m sharing 11 conversations successful Scrum Masters have with their new team within the first 30 days.

The kind of conversations that surface the “invisible stuff.”

Let’s get started.

If you are new to Winning Strategy, check out the posts below that you might have missed

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

2. What does fail fast even mean?

3. Trying to coach an adamant senior

4. How to help silent team members participate?

5. How to handle paused work in Scrum

6. How to setup Continuous Integration?

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

#1: What does good look like for this team?

The goal of this conversation is to align on outcomes and expectations before you start “fixing” anything.

Early on, ideally in your first week, sit down with the Product Owner.

Ask: “When you think of a great Scrum Master, what do they do for you and the team?”

Then: “What two or three outcomes would make you thrilled in six months?”

Next, talk to the team.

Ask:

1. “What things regarding your current working methods must remain unchanged?”

2. “What frustrates you about how you deliver?”

Then look into the future and ask:

“If we see progress in three months, how will your daily life feel different?

This conversation will help you capture expectations and identify those that are not spoken about. You’re not here to impose Scrum, but to work with them to design how you’ll succeed together.

#2: How do we make money and create value?

In your first week or so, try to learn how the product actually creates value. This will help you support better team and product decisions, not just better Scrum events.

Here’s how to do it:

Sit down with the Product Owner, Product Manager, or a senior stakeholder and ask a few powerful questions. For example:

1. “What problems does our product solve, and for whom?”

2. “How do we measure success today, i.e. revenue, retention, conversion, NPS, something else?”

3. “What are the current big bets or strategic themes for this product?”

4. “What’s the cost of delay if we ship slower than we do now?”

Then:

Link this back to day‑to‑day Scrum. For example:

1. “When we’re in Planning or Refining, how can we keep these metrics visible?”

2. “If we had to cut 50% of the backlog, what would we keep and why?

By doing this early, you’re making it clear that Sprint events are about value creation.

#3: How do work and ideas enter this team?

Once you’ve been around for a week or two, it’s time to understand how work actually flows.

Not how it should flow on a process diagram.

The goal of this conversation is to map the workflow from idea → production → value.

Here's how to do it:

Bring the whole team and the Product Owner together. Pick the last release the team shipped.

Ask:

1. “Let’s take the last feature we shipped. Step by step:

   1. how did it start,

   2. who touched it,

   3. where did it wait?”

2. “Where did we get blocked or slowed down?”

3. “Who outside this team can stop or delay our work?”

As your team talks, sketch the following on a whiteboard:

• Triggers: where did requests come from?

• Queues: where did work pile up (analysis, QA, ops, legal, design, etc.)?

• Feedback loops: where did the team get product feedback, user data, or stakeholder input?

By the end of this conversation, you will start to see bottlenecks, such as constant UX wait times or unstable environments, and you and your team will have a shared picture of the current system.

That picture becomes the foundation for future improvements, such as WIP limits and better refinement, etc.

#4: What does “Done” really mean for this team?

In your first couple of weeks, use a Refinement session or Retro to uncover what “Done” actually means for this team.

Do not lecture them about what a DoD should be.

No!

Ask them:

“When we say ‘this is done’, what does that currently include?”

Then talk about the pain points:

“What’s delayed the team in the last few months, i.e. bugs in production, rework, compliance issues?”

Finally:

“What should ‘done’ include so we don’t get those surprises again?”

As they talk, walk through different angles of “done”.

Things like:

• code (merged, reviewed, maybe feature‑flagged),

• testing (unit, integration, exploratory, performance, security),

• documentation (user‑facing and internal),

• product (acceptance criteria and sign‑off), and

• ops (monitoring, alerts, rollback).

Aim for a team-owned Definition of Done, not something you impose. Set a quality level that feels ambitious yet realistic in the current context.

If you’re helping your team create a Definition of Done from scratch, this post might help.

#5: How safe is it to speak up, experiment, and most importantly… fail?

In your first few weeks, you want to understand not just how the team works, but how safe it feels to tell the truth.

You’ll often see the surface level politeness, not what’s not being said.

Here’s how to do it:

In small groups or 1:1s, ask things like:

• “When was the last time someone raised a concern, and it was genuinely welcomed?”

• “When was the last time you tried something that didn’t work, but you still felt it was a good decision?”

You can also probe Scrum: “If you think something the team does in Scrum is pointless, how easy is it to say so?”

In 1:1s, go deeper with questions such as:

“If a new joiner asked you, ‘What should I be careful not to say or do here?’, what would you tell them?”

The answers will disclose the unwritten rules.

You’re not going to fix all cultural issues in 30 days, so DON’T even try.

What you can do, however, is show that YOU are a safe person to talk to and that you’ll protect and encourage honest conversations.

Take a look at the post below for a unique insight into building team cohesion!

#6: How do we want to use Scrum events (really)?

By your second or third week, start exploring how the team actually experiences the Scrum events. The goal is to make the events serve the team and the product, not the other way around.

Approach each event with curiosity as if you want to define a new process for the team.

For Sprint Planning, ask:

1. “What does a useful Sprint Planning look like?”

2. “How do we currently decide what fits in a Sprint?”

3. “What information do you wish we had before committing?”

For the Daily Scrum, go straight to its value:

1. “If Daily Scrum disappeared tomorrow, what would you miss?

2. “What would you celebrate?”

3. “What needs to change so Daily Scrum helps you deliver value, not just report status?”

When you talk about Refinement, focus on preventing the chaos:

1. “How often do we need refinement to avoid last‑minute stress in Planning?”

2. “What makes an item ‘refinement‑ready’?”

For Reviews and Retros:

1. “Who should be at our Reviews to make them genuinely useful?”

2. “What topics are we currently avoiding in Retros?”

From whatever you hear, suggest a few small (not big) experiments.

For example:

“For the next two Sprints, let’s try X in Planning and Y in the Daily, then see if it helps.”

Make it clear you’re not here to enforce rituals.

Scrum is a framework, and together you’ll shape how each event works as long as it stays anchored in transparency, inspection, and adaptation.

7: What’s the real relationship between PO and Team?

Around the middle of your first month, start exploring how Product and Delivery actually work together beyond the polite surface.

Here’s how to have this conversation:

Begin with a joint discussion. Ask:

1. “How do we currently decide what goes into the next Sprint?”

2. “When scope changes mid‑Sprint, what happens in practice?”

Then check the alignment between the PO and the Team:

“How often are we surprised by what was actually delivered versus what was expected?”

The answers will show you how decisions are made and how transparent they are.

Now split.

With the Product Owner in a 1:1, ask:

1. “What do you wish the team did more of to support product outcomes?”

2. “What do you feel are only your responsibilities that you’d prefer to share with the team?”

Also check for pressure from above:

“How comfortable are you saying ‘no’ to stakeholders, given our capacity?”

Now have a 1:1 with the team: 

1. “How easy is it to ask ‘why’ about backlog items?”

2. “Do you feel you can influence what you build, or only how you build it?”

This will reveal whether the team is an active partners in product decisions.

Your goal here is also to make decision boundaries clear:

• who owns priority

• who shapes the scope

• who decides the technical approach

This will also help push more product thinking into the whole team, not just the PO.

#8: What do you need from me, and what do I need from you?

In the second half of your first month, have an honest expectations chat with the team and Product Owner, so you don’t end up as their meeting secretary.

You might say:

1. “Let’s exchange our expectations with each other. What do you need from me to do your best work?”

2. “What should I stop doing if you ever see me doing it?”

Then share your side:

“Here’s what I need from you to be effective in my role…”

This is a good time to spell out how you see your job.

For example:

1. “I’ll help surface impediments, but I need your honesty about what’s really going on.”

2. “I’ll protect focus where I can, but I need you to raise concerns early when you’re overloaded.”

Follow up with 1:1s to make it personal:

1. “How can I support you specifically in this role?”

2. “What’s one thing a past Scrum Master did that you never want to see again?”

This conversation will change your generic “process person” image to that of a “partner” in how the team delivers.

Takeaway

A few suggestions for turning this post into action:

First, you don’t need a bunch of extra meetings. Most of these conversations can live inside things you’re already doing, i.e. Planning, Refinement, Reviews, Retros, or quick 1:1s.

Change the existing agenda instead of sending another invite.

Keep the conversations light. Focus on listening more than talking.

In your first 30 days, your credibility is not built by having all the answers. Specifically, in your first 30 days, your credibility is built by showing that you really understand how the team and the system work before you suggest changes.

Also…

Make a habit of writing things down.

When you hear a clear agreement, write it down. Share it with the team so everyone can see it and correct or refine it.

Once you have these conversations, you will find yourself more confident in your new team.

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 advise 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.

Further Reading

1. 1:1 Interviews to Map Your Team’s Current State

2. 30 Questions to ask a Product Owner

3. Product Ops. What Scrum Masters and Product Owners need to know about this role?

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

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.

Leave a comment

Last week, I attended a workshop with 30 people in the room. Here’s what I observed:

• same 5 people took every decision

• quiet people were…quiet

• the “agreement” in the room was mostly… compliance

I mean… it was a successful session led by an experienced facilitator. We hit the agenda and all.

But… it was incomplete.

During the coffee break, I was speaking with the facilitator when one of the engineers walked up to us and said:

“I had ideas that could have changed our approach… but there was never a good moment to jump in.”

This was awkward for the facilitator.

And I was, once again, reminded of the below antipattern:

Most meetings “accidentally” reward the loudest voice, not the best idea.

And if you (as a facilitator) rely only on “who speaks up,” you are systematically underusing the people who often do the deepest thinking.

In today’s post, I’ll walk you through a simple way to “silence” the room on purpose so that both introverts and extroverts can contribute equally.

Let’s get started.

If you are new to Winning Strategy, check out the posts below that you might have missed

1. Team members don’t turn their camera on during retros and multitask

2. Misconception - Technical debt is only a developer problem

3. Unreliable velocity, making forecasting useless

4. Which Acceptance Criteria are negotiable?

5. Most teams don’t know how and when to use Spikes

6. Non Functional Requirements are Ignored

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

You’re trying to help a senior person (a longtime PM, PO, architect, or manager), and you hit the wall:

“I’ve done agile since ’09, I know this already.”

They claim to be pro-agile. But in practice, you see:

• they have strong opinions based on the old version of agile

• they use lots of “we tried that, it doesn’t work here” with very little data behind it

For you, this creates a coaching trap.

They believe they already have the thing you’re trying to help them with.

So!

How do you handle a team member like that?

Let’s find out.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

“Another retro ended with a superb therapy session.”

Most retros are basically group therapy sessions. Team members vent their frustrations, empathize with each other, and then quickly return to the same unproductive habits they’ve been stuck in.

After the retrospective is over, they leave with feelings (mostly mad and sad), not fixes. Everyone “participates,” but nothing changes.

Don’t get me wrong… venting is healthy.

No doubt!

But teams are there for improvement.

In today's post, I will give you some ways I have seen mature teams use to convert this “Venting” into IMPROVEMENT.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Pause.

No reply.

What do you see? 7 muted mics with 7 blank avatars!

People pretend the meeting was “fine,” then wonder why nothing changes.

Let’s be honest.

If your team is multitasking with cameras off during retros, you’ve got a bigger problem than just “awkward silence.”

Admitting that this happens is already a step ahead of most teams. Many don’t even realize their retrospectives have turned into merely a checkbox exercise.

I’ve been there myself, wondering if anyone was actually listening.

It’s frustrating! No doubt!

But…

It is also fixable.

In this post, I will share how some of the teams I’ve worked with in the past successfully eliminated this problem.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

“Estimation sessions usually get hijacked by the loudest developer(s).”

Raise your hand if you have seen this happening:

1. One or two senior engineers speak first and at length

2. Other team members (often juniors, testers, UX, etc.) defer, nod, or stay silent

3. Story points tend to favour the loudest voice over the collective intelligence of the team

4. Sessions feel longer and less productive.

5. Participants leave thinking, “Why am I even here?”

Have you seen this?

I bet you have!

And when this happens, the result is regular under or over commitment of user stories for the Sprint Backlog and more meetings to “fix our estimates,” which, to be honest, no one likes.

• Why does this happen so often?

• And more importantly, what can you do about it?

In today’s post, I will share some techniques that have proven effective with the teams I have worked with in the past.

Let’s get started.

If you’re new to Winning Strategy, here’s what you missed in the past few weeks

1. How we moved from Scrum to Kanban without disrupting team's ongoing work

2. I spotted 9 problems in a healthy looking team backlog

3. Product Backlog Quick Inspection Template

4. Unclear Acceptance Criteria

5. Non Functional Requirements are Ignored

6. How we fix Knowledge Silos within our teams

Why do the loudest voices win?

“If you know why the fire starts, you can choose the right extinguisher.”
— Fire-safety rule that also applies to meetings

Below are the most common drivers of this kind of dominance.

Recognizing these drivers will help you as a Scrum Master or Product Owner design targeted interventions.

Driver #1: Anchoring Bias

Humans use the first piece of information they hear as a mental “anchor,” even when the anchor is arbitrary.

How it shows up in estimation

1. Senior dev shouts out, “That’s an 8-pointer.”

2. Everyone else’s internal range instantly narrows around 8 (e.g. 5–13 instead of 1–100)

3. Further debate will sound like micro-haggling rather than a genuine exploration of effort

Research

Tversky & Kahneman (1974) showed that merely spinning a “wheel of fortune” with random numbers swayed people’s numerical estimates.

In software teams, studies by Moløkken-Østvold found a 40% reduction in estimate variance when anchors were removed. I highly recommend reading the linked PDF. It’s pretty insightful.

So…

If you consistently see clustered story-point spreads after one voice speaks, you’re watching anchoring in action.

Driver #2: Hierarchy

We often look up to high-status individuals, like architects, principal engineers, or the loud, confident person.

Why?

Because our evolutionary wiring states:

Status = Survival.

Here’s how this shows up

• “She has written most of the code. She must know”

• Junior devs fear they’ll look uninformed

• Product Owner quietly rewrites backlog items mid-meeting to match the architect’s view, instead of clarifying requirements

Driver #3: Lack of structure

Any meeting without clear facilitation turns into a free-for-all conversation, where airtime is determined by personality and not by purpose.

Symptoms

• No time-boxes, no speaking order, no visible agenda

• People talk over one another and drift into solutioning

• Estimates emerge via social negotiation (“Can we agree on a 5 and move on?”) and not discussion

Driver #4: Time pressure

As time becomes more limited, social risk becomes more significant than estimation error.

Under time pressure, most teams tend to quickly come together to maintain harmony rather than focus on accuracy.

You can see this happening when there are:

1. Late-afternoon refinement when everyone wants to leave

2. Release train boundaries (“PI Planning ends at 4 p.m. We have to decide now!”)

3. Facilitators asking, “Can we move on?”

Under time stress, the brain shifts to System 1 thinking (fast, heuristic-based). Disagreeing requires System 2 effort, so silence feels like the rational shortcut.

Driver #5: Blind spot in virtual meetings

In remote settings, (usually) non-verbal cues disappear, making it hard to claim the floor unless you’re already confident.

Here’s how this usually happens:

• A slight microphone delay causes people to yield when they start speaking at the same time as a louder teammate

• “Mute inertia”: person has a thought, but unmuting feels like an interruption risk

• Chat messages are ignored

So…how do we fix this?

Before we jump into “tips & tricks” (that my teams have been using), I think it is important to note what we’re really trying to fix:

1. We want to re-balance airtime, not egos

The goal IS NOT to silence senior engineers; it’s to make sure everyone else can be heard just as easily. A good fix will raise quiet voices without muting experienced ones.

2. We want to replace accidental influence with intentional structure

When dominance arises from randomness, such as the first speaker, loudest mic, or shortest deadline, our fix must introduce deliberate guardrails to level the playing field.

3. We want to surface the information and then let the team decide

Things like estimation should be an information gathering activity first and a decision activity second. The fix must help the team explore the unknowns before they decide on a number.

4. We want to optimize for “Psychological Safety” AND “Speed” simultaneously

Most people think you must choose between “inclusive” and “efficient.” The best practices, however, do both. The meeting time decreases because everyone knows exactly when and how to contribute.

5. We want to make bias visible and then make it boring

Once a team can see what’s going on, i.e. who speaks first, how estimates cluster, etc., they quickly normalize better habits. The fix, therefore, must focus on exposing, not shaming.

With these principles in mind, let’s look at the process my teams follow to fix this problem.

Using Silent, Simultaneous Techniques

Why do we call them “Silent, Simultaneous Techniques”?

Silent because…

Each participant makes their decision without speaking first.

The initial act, i.e. choosing a card or placing a dot, is done privately, so no voice can anchor the group using their tone of voice, confidence, or seniority.

Simultaneous because…

All individual choices are revealed at the same instant: cards flip, dots appear, boards unlock.

Since every vote surfaces together, nobody can “wait and see” which way the wind is blowing before committing.

Bundling these two neutralizes the two distortions below:

1. Anchoring bias (first number rules)

2. Status bias (highest status voice rules)

Prep work before the estimation session

“Preparation removes the oxygen that lets one loud voice set the room on fire.”

1. Slicing stories until they “could finish in ≤1 (or 2) day”.

Why ≤1 (or 2) day?

When the size is small, anchoring bias becomes less effective and consensus forms faster.

If a story resists slicing (it is difficult to split), park it for a structured Backlog Refinement meeting. Don’t try to hash it out inside estimation.

2. Attaching the Definition of Ready checklist to each item in the board.

Definition of Ready = a contract that says, “We won’t waste time estimating half-baked work.”

Example Definition of Ready

☐ Business value statement present  
☐ Acceptance criteria (Gherkin or bullets)  
☐ UI/UX link (Figma, screenshot, or ‘N/A’)  
☐ API / contract link (OpenAPI, protobuf, etc.)  
☐ Non-functional constraints (perf, a11y, i18n)  
☐ Dependencies listed & either resolved or scheduled  
☐ Story sliced to ≤1 dev-day of effort  
☐ Test strategy sketched (unit/integration)  
☐ “Unknowns” section empty or converted to Spike tickets

Scrum Master (or PO) can enforce the rule that says: A ticket cannot move into “Estimating” unless every DoR box is checked.

3. Sending the context to everyone

The PO or a Senior Developer usually does this.

Share the context information 24h (or more) in advance, which includes links to design, spikes, PoC notes, etc.

This helps quiet thinkers come to the meeting well prepared. Extroverts can’t dominate with surprise info.

Here’s how my team’s flow looks:

• PO (and the team) slices backlog items until each satisfies the ≤ 1 day rule (we keep the window extra narrow)

• Each ticket must show a green “DoR” label to enter the Estimation column

• PO publishes the Context information on Wednesday 10:00 am

• Team reviews asynchronously, comments by Thursday 10:00 am

• Estimation session Thursday 14:00 runs with blind voting, high/low explain, and rarely exceeds 20 minutes.

Facilitation tips for Scrum Masters

Here’s what I see them using:

#1: “Parking Lot”

When two voices duel for more than 1 minute, they park the detail for a spike ticket. Decide on size now, and explore the solution later.

#2: “One Breath Rule”

Each speaker may talk until they need a second breath. This forces concise articulation and ALSO levels the seniority gradient.

#3: “Fist of 5”

After the discussion, everyone uses the fist of 5s technique to indicate confidence in the estimate.

Low confidence? Schedule a follow-up instead of endless debate.

#4: Working Agreement

They added “All voices matter” and “Challenge ideas, not people” to their Team Working Agreement.

#5: “No-Anchor” Rule

They start the meeting with:

“Quick reminder: we operate under a No-Anchor Rule. No one voices a number or size until we all reveal together. If it slips out, I’ll interrupt and we’ll reset. No blame, just process.”

The second somebody says a number, the facilitator says,

“Hold that thought. Remember, no anchors. Everyone choose privately first.”

#6: Separating Size from Complexity

The team first lists complexity drivers (like integrations, unknown tech, test data, etc.) in a shared doc. Only after this is done does the team start sizing.

Separating the discussion about complexity drivers from the act of assigning a number forces the team to surface facts first and opinions second.

Listing complexity drivers = divergent thinking (brainstorm risks, unknowns).

Sizing = convergent thinking (collapse to a single number).

Mixing the two confuses the brain and rewards whoever speaks loudest.

This is facilitated in the following manner:

Example

Story: “As a user, I can reset my password via email.”

1. Complexity brainstorm produces:

   • SMTP integration (new)

   • Token encryption key rotation

   • Rate-limiting on endpoint

   • Data-retention check

2. Team privately votes. And then simultaneous reveal: 3, 3, 5, 2, 5

3. Outliers (2 vs. 5) debate discovers the 2-pointers missed Data-retention nuance. Final call = 5

4. Complexity drivers list (brainstorm risks, unknowns, etc.) is pasted into Jira for future reference

That’s how they do it…

The most effective Scrum teams ARE NOT free of loud voices. They put guardrails in place so every voice can be heard.

• They engineer silence into the process (simultaneous reveal)

• They codify expectations up front (working agreements)

• They split backlog items until any single one could be finished in less than a day

• They don’t estimate anything that hasn’t met a visible Definition of Ready

• They arm every teammate with the same context 24 hours in advance

• They run estimation as a facilitated experiment (blind votes, time-boxes, high/low first) instead of an open mic debate

No guesswork.

Just shared understanding and a forecast that the whole team owns.

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.

Leave a comment

Further Reading

1. Backlog Refinement Session Checklist

2. Backlog Management Events and Training Deck

3. How To Distribute Product Backlog Items To Multiple Teams?

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

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.

Knowledge silos quietly form inside teams even when everyone’s talented and well-intentioned.

It starts small: one person owns the workaround, another handles the tool. And before you know it, information is locked away, and progress declines the moment someone moves on.

Have you witnessed this?

I’ve watched teams struggle with this, and I’ve been part of teams that finally broke through this problem as well.

The difference?

They stopped accepting silos as “just the way things are” and got intentional about sharing what they knew.

In this post, I’ll share the steps teams I’ve worked with used to break down knowledge silos.

If you’ve ever worried your team is one vacation away from chaos, this one’s for you.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

"Why can't they just...get it?"

Being part of a team can feel like a game of chess.

Everyone has a unique role, and success depends on how well you understand the "moves" of those around you.

So, how do you “crack the code” of working well with your team?

I've collected a few TED Talks and, over the past few weeks, have felt the urge to share them with you here.

Hope you find them useful.

#1: Kelly McGonigal – “How to Make Stress Your Friend”

Sustainable pace (Agile Principle #8) depends on reframing pressure as an ally, rather than a source of burnout.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Q: I'm dealing with a situation where one team member consistently dominates our Scrum ceremonies, especially Daily Standups and Sprint Planning. This sometimes discourages quieter team members from sharing their thoughts. How do I stop this person from talking too much? I'm not sure how to address this without making him feel singled out. Can you provide some ideas that worked for you in the past?

Absolutely!

Thank you for the question.

Let me start by bringing the focus to your core question:

“How do I stop this person from talking too much?”

This question is making your problem sound more tactical.

It is not!

Under the surface, it is a systemic problem that touches on the foundations of Scrum and team psychology.

Surface symptoms

• One developer is dominating airtime

• Quieter members are staying silent

This is the observable behaviour… what we can see and measure.

Under the surface

1. There is a lack of psychological safety

2. Matthew Effect is in play, i.e. the more someone talks, the more people assume they are the expert, so the loop reinforces itself

3. There are some facilitation gaps

4. The vocal person might be a senior engineer, an ex-tech lead, or simply an extroverted individual. Title or personality can overshadow role equality within the Scrum teams

So the question is not merely “how to quiet a talkative teammate?”

Doing that would be rude!

The question is, “how to restore balanced participation so Scrum can work?”

With that in mind, let’s see how we can achieve this.

Read more

I've been leading teams for years, and if there's one skill I wish I'd mastered early in my career, it's Assertiveness.

The post title says it’s an essential skill… It’s not merely that.

It's the make-or-break factor for someone who really wants to help their team AND themselves succeed.

I once had this brilliant team, full of potential, but they missed opportunities because their leader (that’s me) was too afraid to step up and say what needed to be said.

It was frustrating and, honestly, a total waste of everyone's talent.

Mastering Assertiveness allowed me to cut through the BS and improved my team’s chances of succeeding.

“So why aren't more people doing this?”

Because they think that being Assertive will come across as pushy. They confuse Assertiveness with being a bully.

THIS IS NOT THE CASE!

Assertiveness is straightforward, powerful stuff.

It boils down to two things I live by:

1. speaking your mind with confidence, and

2. commanding respect “without” being mean (this is important) to people

Nothing more. Nothing less.

If you are missing this skill, you're probably not leading as effectively as you could be.

In this post, I'll share my take on:

• What assertiveness really means

• 7 communication tricks I've been using to be Assertive

Let’s get started.

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

1. KPIs for Scrum Mastery

2. How Hiring Managers Assess Soft Skills?

3. How to Influence Without Authority?

4. How do you record skills and strengths of your team members?

5. 4 Types of People Who Can Make or Break Your Scrum Team

6. When Stakeholders Don't Have Time for UAT.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

What assertiveness really means

Let’s start with what Assertiveness is NOT.

Assertiveness is not being the loudest voice in the room or the quietest. It’s not steamrolling people. Also it is not rolling over and playing dead.

NO!

Assertiveness is the CONFIDENT and DIRECT expression of your thoughts while still showing respect for everyone else.

As a new Scrum Master, I thought I had two options:

1. Speak up and push my way through disagreements (aggressive), or

2. Keep the peace at all costs, even if it meant biting my tongue (passive)

Neither worked.

Both approaches left me frustrated and misunderstood,

Assertiveness is somewhere in the middle.

When you are Passive:

You nod along, avoid conflict, and let others’ needs always take priority. You walk away from conversations thinking, “Why didn’t I say what I really meant?”

When you are Aggressive:

You push, you interrupt, you maybe even intimidate people into agreeing. You get your way, but at the cost of trust and team spirit.

When you are Assertive (the sweet spot):

You speak up. You’re honest, direct, but also calm. You set boundaries and say what needs to be said, without turning it into a showdown.

It takes courage… no doubt. But you do it anyway.

Examples:

Assertiveness is standing up for what is right. It’s:

• Positive

• Respectful

• Honest

• Straightforward, and

• Calm

When you find this sweet spot, people start listening to you, and you start to influence people (no authority needed).

How do you develop this skill?

With Practice...

I know, it sounds like the most clichéd advice ever. Hear me out though.

In the world of Scrum Mastering, Assertiveness is not a superpower you either have or you don't.

It is a skill you build, one stand-up or retrospective at a time.

It needs:

1. repetition,

2. courage, and

3. a willingness to screw up and try again

I remember when I was learning to be assertive with my team. My voice used to shake a little. It wasn't very comfortable. But it worked better than staying silent.

The next time, it was easier.

The time after that, it felt… natural. The more you use it, the stronger it gets.

But how do you do it?

Below are 7 communication techniques I have been using to be Assertive.

#1: Agreeing

If you want someone to agree with you, start by showing your agreement first.

I know. It sounds almost backwards.

Not if you listen to Psychology.

According to psychology, people are way more likely to listen (and even shift their stance) if they feel you get where they’re coming from.

How to use it?

Let’s say you’re trying to sell your team on pair programming.

Don’t jump straight into why it’s a great idea. Start by acknowledging their hesitation:

“I know pairing sounds crazy and like a waste of time at first…”

Here, you’re validating their concerns. You’re not dismissing their perspective. By doing this, you lower their defences and open the door for a conversation.

Once you’ve made that connection, you can confidently follow up with your reasoning:

“…but teams who’ve tried it often find it improves collaboration, catches mistakes early, and speeds up delivery in the long run.”

Agreeing doesn’t mean you give up your stance.

No!

You start the conversation on a “common ground” and guide it toward a solution.

#2: Scheduling a time in future

When you’re introducing a new suggestion, it’s natural for the team to hesitate, especially if it’s something they’ve never tried before.

What to do?

Don’t push!

Ask them to schedule a time in the future to test your suggestion out.

It works because it lowers the pressure (on the team) for an immediate decision.

Example:

You: Has the team ever tried dedicated technical debt sessions before?

Them: No.

You: Okay. How about we schedule one session next sprint, just to test it out?"

You’re not demanding they buy in right this second. You’re inviting them to experiment in the future, when there’s less pressure.

The key is in the phrasing:

• "Can we schedule..."

• "Would next week work to try..."

• "How about we experiment with this in the next sprint..."

You're not asking IF anymore. You're asking WHEN.

And…once it's scheduled, it becomes real.

#3: Asking to rate feelings

When introducing a new suggestion, it’s important to gauge your team's reaction to it. A simple but effective way to do this is by asking them to rate their feelings on a scale of 1-10.

It helps you understand their level of enthusiasm (or hesitation) without needing a long discussion.

Here’s how.

Let’s say you’re proposing the use of WIP Limits, but you’re not sure how the team feels about it. You ask:

“On a scale of 1-10, how excited are you about the idea?”

Let’s assume someone says “3.”

This opens the door for further discussion. Your next question is now obvious:

"What would make it a 6?"

You're not defending your idea, you're collaboratively improving it.

Why does this work?

This works because numbers feel safe.

Most people hate confrontation, but they’ll happily pick a number. This provides you with data. Maybe everyone’s a 3 (okay, that’s a clue you need to rethink or re-explain). But maybe you get a few 7s, a couple of 5s, and one 9. Now you can have a genuine conversation about what’s holding people back (or what’s getting them interested).

I use this all the time, especially with hesitant teams.

It’s a low-pressure way to surface hidden objections and supporters. Plus, it models Assertiveness.

In short: Don’t guess what people feel. Ask!

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.

Get more from Vibhor Chandel in the Substack app

Available for iOS and Android

Get the app

#4: Highlighting the status quo

Here's the thing about human beings: We hate losing more than we love winning. Way more. Like, twice as much more.

And do you know what we hate losing the most?

Opportunities!

For this reason, one of the most effective ways to encourage your team to try something new is by highlighting the risks of sticking to the status quo.

Example:

Let’s say your team is still using hourly estimation for user stories, and you’re proposing switching to story point relative estimation.

What to do?

Don't spend your energy highlighting the benefits of story points. Instead, focus on the risks of relying on hourly estimation:

“Here's what typically happens with hourly estimates: teams spend hours debating if something will take 16 or 20 hours, stakeholders treat hourly estimates as commitments, and developers feel pressured when they exceed their hours.

We can avoid that completely by trying relative estimation with story points, which helps teams focus on complexity and effort rather than time.”

This makes the choice clear:

Stick with the status quo and risk repeating common problems, or try something new (different) and avoid those pitfalls.

In short: You can be Assertive by making the cost of not changing crystal clear.

#5: Showing concern

When proposing a change, it is important to show that your motivation stems from genuine concern for the team’s success.

Showing that you’re invested in their growth and well-being can make them more receptive to your ideas.

Example:

Let’s say your team has been skipping retrospectives, and you’re worried about the long-term impact. Instead of telling them to get back on track by saying:

"The team needs to take retrospectives seriously."

You express your concern:

“I’m concerned that if our high-performing team continues to ignore retrospectives, we'll lose the edge that makes us special."

One sounds like a complaint.

The other shows you care about the team's future.

Caution: The concern has to be genuine. People can smell fake concern from a mile away.

When people sense you genuinely care about them and their success, their defensive walls come down. They stop hearing criticism and start hearing collaboration.

In short: You can be Assertive by letting them see that you genuinely care about their success.

#6: Using “because…”

A tiny word with massive persuasive power: “because…”

This comes from Robert Cialdini's research:

“For human beings, whatever comes after ‘because’ justifies what comes before.”

It sounds almost too simple, but it works.

When you give a reason, even a basic one, people are much more likely to go along with your suggestion. Our brains are wired to want explanations, and the word “because” flips that mental switch.

Let’s say you’re encouraging the team to hold regular retrospectives. Instead of simply stating that the team needs to do them, you explain why:

“Our team needs a regular retrospective because it helps us identify what’s working, what’s not, and how we can continuously improve.”

By including “because”, you provide a clear rationale behind your suggestion. And it feels not just reasonable but necessary.

In short: You can be Assertive by using the word “because…” to provide the rationale behind your suggestion.

#7: Identifying what’s stopping them?

When your team resists an idea or change, it’s important to understand the root cause of their hesitation.

I don’t know about you, but when I was a new Scrum Master, I assumed that resistance meant (outright) rejection.

Not true.

More often, it meant that there was an obstacle in the team’s way that was making them hesitate.

Here’s how to use this knowledge:

Me: "We should implement automated testing."

Team: lukewarm response

(Find the root cause.)

Me: "If we had dedicated time in the sprint for this, would you be open to starting?"

Team: "Actually, yes. That's been the main concern."

Formula:

Notice resistance → Ask (or find out) about obstacles → Focus on removing those obstacles → Confirm if that would clear the path

Caution: Sometimes people have multiple obstacles. Keep asking "What else would need to be addressed?"

Most resistance isn't for your idea. It's for these obstacles that people see in implementing it.

In short: You can be Assertive by identifying what’s stopping them and then helping them remove what’s stopping them.

The Journey Forward

Here’s my final word on Assertiveness: only use it when you genuinely believe in your suggestion.

(Assertion) minus (Belief) = (Aggression)

Belief gives your assertions credibility. If you assert something without conviction, it will feel forced.

So!

Before making any assertion, ask yourself:

• Do I truly believe this will help the team?

• Can I clearly state why this is the right way forward?

If the answer is yes, present your idea with confidence and clarity.

If not, take time to gather more information before being Assertive.

Further Reading

1. Proven Mental Models for Scrum Masters

2. Signs You Have a Good Manager

3. Laws of Highly Effective Agile Reports

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

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.

Here’s something that happens with every Scrum Master:

You join a new team, excited to help them improve their productivity. But as you sit in your first few meetings, you notice things are not quite flowing the way they should.

• the daily standups feel like status reports

• the sprint reviews lack meaningful stakeholder engagement

• the retrospectives are quiet, with team members reluctant to speak up

And you're wondering: "Should I jump in and fix everything right away?"

The most effective Scrum Masters I've known don't rush to make changes. They start with careful observation.

When you enter a new team, you think like a Doctor. Before prescribing any treatment, you observe symptoms, check vital signs, and understand the whole picture.

In this post, I'll share a guide for observing your team's Scrum events. You'll learn:

• What to observe?

• How to turn your observations into action?

• When to step in and when to step back?

Let's get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

General observation guidelines

1. Show up early, camera on (if remote).

2. Set clear expectations up-front: “I’ll just watch and take notes so I learn your current rhythm. No judgment. I'm here to understand." This simple statement does two powerful things:

   • It puts the team at ease

   • It gives you permission to be the quiet observer

3. Keep a low profile: The moment you interfere, you change the natural behaviour you're trying to observe. This means:

   • No facilitation

   • No coaching

   • No jumping into solving problems

   • No "helpful suggestions"

   • Just watch. Take notes. Let the team's natural dynamics unfold

4. Write down plain observations, not conclusions. Quote people verbatim where possible (Note: these quotes are not for everyone to see)

5. Right after each meeting (and I mean right after, while it's fresh), do this quick exercise:

   🟢 Green: Mark the strengths you observed
   🟡 Yellow: Note anything that's unclear or needs more observation
   🟤 Red: Flag potential impediments

6. Don't jump to conclusions. These red flags? They're not problems yet. They're just observations that need validation

7. Park your hypotheses: Validate them later with the team

Your brain will want to diagnose issues immediately. That's natural. We're problem solvers by nature. But resist that urge.

Resist the urge to think, "They're doing standups wrong."

Think, "Question to explore: What's the team's goal for their daily standup?"

Remember: Observation is similar to building a puzzle. You need all the pieces before you can see the whole picture.

Daily Scrum (observe 2–3 occurrences)

I have written a detailed post on what to “note” during daily standups. You can check it out at the link below:

What do I note during daily stand-ups?

Here’s a summary of what to observe:

Read more