He had a good team. They were falling apart.

Not because of the mission. Not because of the environment. Because of him — not his intentions, but his grip. Too tight. Too far into the details. Too present in decisions that weren’t his to make.

The team felt it. They always do.

What started as tension became open conflict. In an environment where that kind of distraction has real consequences.

I didn’t walk in with a framework. I watched. Asked questions. Tried to understand what was actually happening versus what he thought was happening.

Those were two very different things.

He was leading the team in front of him through the lens of teams he’d led before. Old failures. Old distrust. None of it relevant. All of it in the room.

The shift wasn’t complicated. He owned strategy. They owned execution. That’s it. But getting him to actually let go — to trust that the work would get done without him in the middle of it — took time. Real conversations. Small moments where he stepped back and watched things go right.

Slowly it clicked.

The conflict settled. Focus came back. The team started solving problems instead of creating them.

He didn’t become a different leader overnight. But he became a better one. Because he was finally seeing clearly.

Too much control isn’t strength. It’s noise. And noise gets people hurt.

Subscribe now

Some teams don’t have a skill problem. They have a decision problem.

When I joined this team, they’d been trying to launch a consumer app for five months. Five months of meetings, debates, revisions, and missed deadlines. The talent was there. The intentions were good. But the app wasn’t shipping.

I’ve seen this before — not in tech, but in places where the cost of paralysis is measured differently. Overseas, in high-stakes environments where waiting for perfect information isn’t a strategy, it’s a liability. What I learned there translates directly to product teams, delivery teams, any team where complexity creates confusion and confusion kills momentum.

Here’s what we did. And it wasn’t complicated.

We stopped talking about what we wanted and started deciding what we’d say no to.

That’s it. That’s the unlock.

Most stuck teams have too many priorities — which means they actually have none. Everything feels urgent. Nothing gets finished. People are busy but nothing ships.

We sat down and ruthlessly cut. Features, scope, nice-to-haves, someone’s pet idea. If it wasn’t essential to getting this product into a user’s hands and learning something real, it went on a list for later. Maybe forever.

Then we planned around what remained. Not a perfect plan — an executable one. There’s a difference.

Then we executed. Heads down, clear lanes, no new priorities sneaking in the back door.

Then we shipped.

Then we measured what actually happened when real users touched it — and let that drive what came next.

Prioritize. Plan. Execute. Measure. It sounds almost insultingly simple. But simple is what works when pressure is high and time is short. I learned that long before I ever worked in tech.

That’s what AgileAF is about.

Not frameworks for the sake of frameworks. Not Agile theater. The real mechanics of how teams perform when it matters — drawn from 20 years of military service and 15 years of IT delivery.

Some lessons you learn in a boardroom. Others you learn in places where the stakes are higher. Both show up here.

Subscribe now

Most problems don’t fail at execution. They fail much earlier — when someone skips ahead without a real plan, or when results are never reviewed because the team moved on too fast.

The teams that consistently win aren’t always the most talented. They’re the most systematic. Here’s the framework I keep coming back to.

1. Prioritize — what actually matters right now

Every problem comes packaged with noise. The first move is to cut through it. Good prioritization is ruthless: if you could only work on one thing this week, what would move the needle most? The real skill is the honesty to deprioritize things you like in favor of things that matter.

2. Plan — map the path before you march

Once you know what to solve, get clear on how. A real plan names the steps, assigns ownership, and identifies the risks that could derail everything. It doesn’t need to be a 40-slide deck — it just needs to answer: what’s the sequence, who’s responsible, and what could go wrong?

3. Execute — momentum over perfection

The biggest trap here isn’t laziness — it’s over-engineering. Waiting for the perfect moment, the perfect version, the perfect conditions. They don’t come. Bias toward action. A done-at-80% solution that’s in the world teaches you far more than a perfect plan that never shipped.

4. Measure Outcomes — close the loop

Execution without measurement is just activity. Ask: did it work? What did we learn? What would we do differently? This is the most skipped step — and the most valuable. Done well, it doesn’t just evaluate the last project. It feeds the next one.

This isn’t a checklist — it’s a loop. Every time you measure outcomes, you get smarter about what to prioritize next. The teams that compound their results are just running this cycle, over and over, a little better each time.

Problems Are the Job

No one would need you if there weren’t problems demanding your attention.

Problem solving is the gig—whether you're writing code, building teams, or architecting the future. So stop playing blinders while the real work passes you by:

• Are you so hyper‑focused you’re missing the forest for the trees?

• Are you rejecting ideas before they even land?

• Have you decided nobody else could possibly be right?

Pause. Then Pivot.

When you’re stuck, staring harder isn’t the answer. Pull back. See the full field.

Problems aren’t interruptions—they are the work. Every solved issue is a win and a chance to sharpen your craft. And if you don’t reflect on past fixes, you're doomed to repeat them.

Been There, Undone That

I once supported a team trapped in a grind of “do and undo.” They were ready to quit. My advice: “We’ve been here before. We know what to do.”

Look, solving the same problem gets old. That’s your cue to level up. But leveling up doesn’t mean escaping problems—they just get harder. Your job becomes guiding others, thinking strategically, and setting direction—not executing it all yourself.

Pressure & Perspective

Life is just problem after problem. There’s no rest—and that’s fine. The win is being ready when the next one hits.

Experience changes how you respond. You stop reacting, start pacing, manage disruption. That calm under fire? Most people don’t even know what they’re missing—until they see it in others. As Jocko Willink puts it:

“With each of those problems, I am the solution. With each problem I solve, the level of trust the boss has in me goes up.” themindcollection.comgoodreads.comtime.com+5bookroo.com+5yesware.com+5

Every problem you solve makes you the person they trust next time.

Problems aren’t interruptions—they are the path. Your value isn’t avoiding them—it’s how you navigate them—with perspective, patience, and purpose.

AI-Aided Retrospectives: What Actually Helps (and What Doesn’t)

AI isn’t replacing facilitation—but it is starting to influence how retrospectives get designed, analyzed, and misunderstood. Use it well, and you get time back to focus on group energy and insight. Use it poorly, and you dull the room.

Here’s what works—and what doesn’t.

What Helps

Agenda Design
Use AI to remix retro formats or surface better framing. Example: “What risk are we tolerating that no one’s naming?”

Synthesis of Feedback
AI can quickly cluster themes from freeform input, especially in async or distributed contexts. Treat it as pre-work, not the outcome.

Facilitator Prep
It’s a solid assistant to rehearse reframing, brainstorm better prompts, or simulate likely tensions before the session.

What Hurts

Tone & Context Misses
AI can’t read the room. It can mislabel sarcasm, humor, or disagreement as negativity.

Premature Theming
Letting AI group things too early kills productive tension. Sometimes the point is that things feel unresolved.

Participant Apathy
Too much automation makes retros feel like reporting. If no one has to think, no one reflects.

How to Use It

Treat AI like a junior co-facilitator. Ask it:

• “Suggest 3 fresh retro formats for a low-trust team.”

• “What are reframing options for a blame-heavy topic?”

Don’t let it:

• Set tone

• Interpret emotion

• Summarize too early

Bottom line:
AI can scan the noise. You hold the meaning. Let it be messy. Conflict and disagreement is the agent of change.
Use it to create space, not conclusions.

Scrum Masters sometimes think: “If my teams can run at a high level without me, I’m out of a job.”

• You’re thinking too small. When teams deliver without you, you get bigger, better opportunities—not unemployment. Charles Duhigg’s Smarter Faster Better shows leaders of autonomous teams often advance faster because they’ve proven they can build lasting effectiveness.

• Stop proving, start delivering. Too many Scrum Masters focus on looking valuable instead of improving team capability. The Liberators’ work on team autonomy shows the more you enable self-organization, the more value you create.

• Ditch the artifact mindset. Many come from output-heavy roles where plans, reports, and Excel docs proved worth. Harvard Business Review warns this focus on outputs over outcomes is a major blocker to Agile success.

• Make the hard shift. Moving from controlling decisions to asking, “What do you think you should do?” feels like letting go, but MIT Sloan Management Review shows that when leaders stop solving every problem, teams build capability and ownership.

• Work yourself out of the day-to-day. If your teams rely on you for every answer, you’ll keep solving the same problems forever—and never have space for bigger challenges.

• Intervene only when it matters. Let them live with their solutions. Commitment comes from carrying the results, not just agreeing to them.

The less they need you, the better you’ve done your job.

In fast-moving teams, confusing perception with perspective creates unnecessary conflict and bad calls. Know the difference.

Perception is your immediate reaction.
It’s emotional. It’s biased. It’s shaped by your past.
It’s how something feels.

Perspective is your chosen angle.
It’s reflective. It’s intentional.
It’s how you frame what you’re seeing.

Psychologist Daniel Kahneman described this well: System 1 thinking is fast and instinctive (perception); System 2 is slower, deliberate, and rational (perspective). Most people live in System 1. Great leaders don’t.

When a sprint veers off course or a stakeholder challenges your priorities, your perception might want to push back. Your perspective gives you space to assess and respond instead of react.

Perception is reactive.
Perspective is reflective.
Leading with the latter turns chaos into clarity.

Apply it:

• When the team resists a change, don’t assume laziness (perception); consider past burnout or trust gaps (perspective).

• When a PO shuts down feedback, don’t assume arrogance; maybe they’re under pressure you can’t see.

Lyssa Adkins, in Coaching Agile Teams, pushes Agile coaches to develop this exact muscle—to pause, zoom out, and help teams shift out of emotional reaction into shared understanding.

If you want clarity, don’t just trust your gut—train your view. Shift from how it feels to what else might be true.

Disagreements between a Scrum Master and a Product Owner aren’t a red flag. They’re part of the job. If you never bump heads, someone’s probably not showing up fully.

But when the friction hits, what matters most is what you do next.

Your Role Isn’t Control—It’s Effectiveness

Let’s set this straight: your job as a Scrum Master is team effectiveness, not control.

Not enforcing the perfect Scrum template.

Not protecting the process at all costs.

Not winning debates with the PO.

You’re there to help the team plan, prioritize, and deliver outcomes. That often means letting go of the need to steer everything and learning to guide instead.

The best Scrum Masters lead like a good field commander: clear intent, strong direction, and trust in the team to execute. You influence the system—you don’t micromanage it.

Don’t Pick Sides—Guide Both

When the PO’s priorities feel off or they start acting like a task manager, don’t default to confrontation or avoidance.

Instead:

• Remind the PO they own the backlog, not the team’s task list.

• Recenter on outcomes, not activity.

• Facilitate conversations that uncover blockers and misalignment—not just point fingers.

Disagreement is fine—as long as everyone’s clear on roles and responsibilities. The PO focuses on maximizing product value. You focus on enabling the team to deliver. That overlap is where your partnership matters most.

It’s Okay to Work with People You Don’t Like

Let’s be real: you won’t always like the PO. You might not even respect their product sense. That’s life.

But you can still find common ground.

The goal isn’t to be best friends—it’s to align on outcomes, solve problems, and keep delivery flowing. The moment personal preference gets in the way of professional progress, you’ve lost the thread.

Professional disagreement is a feature, not a bug. If nobody challenges the thinking, nothing gets better.

Speak Up. Facilitate. Move Forward.

When conflict shows up, don’t avoid it. Don’t escalate it, either.

Step into it.
Make the problem visible. Frame the conversation. Ask the hard questions. That’s where your value lives.

• “What problem are we trying to solve?”

• “How does this priority serve the product goal?”

• “Where is the team struggling to flow work?”

You’re there to create the conditions for clarity and collaboration. Not by forcing agreement—but by guiding people to it.

Final Word: Influence > Control

If your instinct as a Scrum Master is to “get control back,” pause.

Instead, ask:

“What can I influence that helps this team get unstuck and deliver value?”

Then start there.

Outcomes over egos.
Clarity over control.
Trust over task-wrangling.

That’s the path.

Standups Aren’t Surveillance

What’s wrong:
When standups become status briefings for leadership, they stop serving the team. The meeting turns into theater, blockers stay buried, and collaboration flatlines.

What’s actually true:

• Standups are for team alignment, not management inspection.

• It’s about shared context and quick course corrections.

• Format should flex—rigid routines kill usefulness.

Why it matters:
When people treat standups like daily performance reviews, they self-censor. Psychological safety drops, risks hide, and momentum dies.

Force multiplier:
Scrum Masters who reframe standup as a team-owned sync unlock real-time coordination and faster, smarter decisions.

Bottom line:
If your standup feels like surveillance, the problem isn’t the format—it’s the culture. Fix that first.

Agile teams don’t fail from being busy.
They fail from chasing noise instead of building value.

Cognitive load is necessary for growth.
Without direction, it breaks teams. With direction, it sharpens them.

How high-performing teams turn load into leverage:

Clear Product Vision

• Anchor to a long-term goal.

• Don’t derail sprints for unvetted ideas.

• Log ideas, refine them, address in planning.

• Disruption kills flow and trust.

Prioritize Ruthlessly

• Treat the backlog as a filter, not a catch-all.

• Focus on what moves the customer needle.

• Measure outcomes like lead time and flow efficiency—not vanity metrics.

Technical Leadership that Clarifies

• Tech leads guide decisions, reduce churn.

• Don’t ask every dev to solve foundational problems.

• Alignment enables progress without micromanagement.

Self-Regulating Teams

• Everyone should be able to say:
  “I’m overloaded.” “This doesn’t make sense.” “We’re off course.”

• Psychological safety enables clarity, not comfort.

• Self-awareness is a team skill. Build it.

Don’t avoid cognitive load. Direct it.
Reduce waste. Drive momentum.

Myth: Agile only works for small teams—it doesn’t scale.

Why this is wrong:
Agile can scale—but it doesn’t scale by slapping Scrum across 30 teams and hoping alignment happens. Most failures come from scaling processes without scaling principles, leadership support, or systems thinking.

What’s actually true:

• Agile scales when teams are aligned by purpose, not just tools.

• Large organizations succeed with Agile by investing in empowered teams, decentralized decision-making, and shared outcomes.

• Frameworks like SAFe, LeSS, and Spotify offer patterns—not plug-and-play solutions.

Why this matters:
Believing Agile can’t scale becomes a convenient excuse to stick with bloated governance and waterfall roadmaps. The result? Slower learning, delayed feedback, and expensive “transformations” that never transform.

Force multiplier insight:
Scrum Masters and coaches who focus on principles—flow, feedback, autonomy—help scale Agile by enabling coherence, not conformity.

Agile scales when you scale principled thinking and outcome focus—not just standups. Stop copy-pasting and start architecting.

From the Scrum Expansion Pack — pragmatic tools and patterns for modern teams who want more than rituals and velocity.

Most Agile teams are great at getting to Output Done.

The feature is built.
It meets acceptance criteria.
It’s deployed.
It’s marked “done.”

But here’s the catch: that’s just delivery—not impact.

Output Done vs. Outcome Done

Output Done means:

• The thing was shipped.

• The sprint goal was checked off.

• The team can move on.

Outcome Done means:

• The thing delivered actual value.

• A real customer pain was solved.

• User behavior changed.

• The business saw results.

If we stop at Output, we’re just tracking effort—not effectiveness.

Agile was never about shipping for the sake of shipping.
It’s about delivering outcomes that matter.

A Better Question for Retros

Next time you wrap a sprint, try asking:

Did we finish the work—or did we make a difference?

Because “done” should mean more than code in production.
It should mean progress.

Share

If you’ve ever sat in a retrospective that felt more like theater than progress—or watched a “Scrum” team operate more like a slow-moving waterfall—you already know the problem:

Agile has been consumed by cargo cults and coated in jargon.

That’s why I built Agile Whiskey Bot — an AI-powered assistant for leaders and teams who want real results, not rituals.

What It Does

Agile Whiskey Bot answers questions like:

• How do I lead a team that’s checked out?

• How do I model a daily scrum that actually helps?

• What’s a better metric than velocity?

• How do I coach a Product Owner who just says yes to everything?

It’s built for:

• Team leads, managers, and delivery folks

• Scrum Masters and Agile coaches

• Anyone trying to lead with clarity in complex environments

Try it for yourself:

Launch Agile Whiskey Bot

Whether you’re coaching execs, digging a team out of dysfunction, or just tired of googling for real Agile advice — this bot delivers the goods. No fluff. No cult talk. Just straight answers, served neat.

Let me know what you think — and feel free to reply with ideas or feedback.

Subscribe now

Use this playbook as your hub—each ➜ link jumps to a deeper drill-down on AgileAndFocused.com so you can expand or troubleshoot any step.

1. Craft a Directional Vision

Paint the future state your product unlocks in vivid, emotional language—what users will feel, achieve, or avoid. Skip numbers; give teams a narrative test (“Will this move us toward effortless, minutes-to-master onboarding?”). Metrics refine the route later; the story keeps everyone rowing the same way. ➜ Read: The Importance of Strategic Planning

2. Shape a Strategy-Aligned Backlog

Map each outcome to thin vertical slices. Prioritize by risk and impact, not politics. Keep a playback board linking backlog item → outcome → vision so choices stay product-centric. ➜ Read: Backlog Refinement Is Not a Planning Meeting — It’s a Focus Filter

Subscribe now

3. Orchestrate Execution with DevOps Scrum Masters

A DevOps-savvy Scrum Master connects code pipelines to strategy, removes systemic blockers, and ensures “done” means deployed with telemetry. ➜ Read: Scrum Masters, It’s Time to Care About DevOps

4. Run Dual-Cadence Inspect & Adapt

• Sprint cadence (1–2 weeks) validates increments.

• Strategic cadence (4–6 weeks) reviews outcome metrics, re-tests assumptions, and reallocates investment.
  Keeping the two rhythms in sync lets teams ship quickly while the business stays on track. ➜ Read: Agile Doesn’t Mean “No Plan” – It Means “No BS Plans”

5. Nurture a Resilient Culture

Psychological safety fuels experimentation; over-protection breeds complacency. Pair candor with accountability so teams feel safe to try and compelled to deliver. ➜ Read: When Psychological Safety Goes Too Far

6. Close the Learning Loop

Keep a living strategy log that records the vision and key choices, giving future releases a clear compass instead of repeating past detours. ➜ Read: Agile Doesn’t Kill Documentation — It Kills Pointless Documentation

Share

Leave a comment

Myth: The Scrum Master just runs standups and retros.

Why this is wrong:
Reducing the Scrum Master to a “meeting manager” completely misses their purpose. Their role is to coach the team, remove blockers, build psychological safety, and help the organization understand what real agility looks like.

What’s actually true:

• A great Scrum Master improves how the team collaborates, plans, and delivers.

• They coach product ownership, influence stakeholders, and challenge the status quo.

• Their impact should be seen in team health, flow of work, and outcome clarity—not just calendar invites.

Why this matters:
When teams treat Scrum Masters like admin support, they get shallow agility. Engagement drops, dysfunction festers, and teams stagnate behind ceremonies with no substance.

Force multiplier insight:
True Scrum Masters multiply team effectiveness by shaping culture, clearing paths, and driving continuous improvement.

Takeaway:
Scrum Masters aren’t facilitators—they’re force multipliers. If you’re not feeling the impact, you’re missing the role.

Myth: Agile means no documentation.

Why this is wrong:
This myth stems from a misread of the Agile Manifesto, which favors “working software over comprehensive documentation.” It doesn’t say “no documentation”—it says prioritize value. Writing specs no one uses, or ten-page test plans for two-week sprints, is the problem.

What’s actually true:

• Agile teams create just enough documentation to support delivery.

• Good documentation helps with onboarding, testing, and knowledge sharing.

• The goal is useful, lean artifacts—living documents, not deadweight PDFs.

Why this matters:
When teams avoid documenting entirely, they lose continuity. New team members struggle. Quality dips. Decisions get repeated—or forgotten. Agile done right values clarity, not clutter.

Force multiplier insight:
Scrum Masters who help teams strike the right documentation balance amplify shared understanding and team resilience.

Takeaway:
Agile doesn’t reject documentation. It rejects waste. Write what matters. Skip what doesn’t.

Myth: Scrum and Agile are the same thing.

Why this is incorrect:
Agile is not a specific process or methodology; it's a set of values and principles outlined in the Agile Manifesto. Scrum is one of several frameworks that implement these principles.

What’s actually true:

• Agile emphasizes values like customer collaboration, responding to change, and delivering working software frequently.

• Scrum provides a structured approach with defined roles, events, and artifacts to implement Agile principles.

• Other frameworks like Kanban, Extreme Programming (XP), and Lean also embody Agile principles in different ways.

Why this matters:
Conflating Scrum with Agile can lead teams to focus solely on Scrum's mechanics, neglecting the underlying Agile principles. This often results in "doing Agile" without "being Agile," where teams follow Scrum rituals without embracing the flexibility and continuous improvement that Agile promotes.

Force multiplier insight:
Scrum Masters who emphasize Agile principles over rigid adherence to Scrum practices enable teams to adapt processes to their unique contexts, fostering true agility.

Takeaway:
Scrum is a tool to implement Agile principles—not a synonym for Agile itself. Embrace the principles to guide your practices, not the other way around.

Myth: Velocity measures how productive the team is.

Why this is wrong:
Velocity measures output, not outcomes. It’s a tool for forecasting, not a KPI for performance. When leadership equates velocity with productivity, teams start gaming the numbers—padding estimates, cutting corners, and focusing on throughput over value.

What’s actually true:

• Velocity is useful for estimating capacity, not judging performance.

• Productivity in Agile is better reflected by outcomes, customer feedback, and cycle time.

• Consistent velocity helps teams, not managers, plan work more effectively.

Why this matters:
Chasing higher velocity kills quality, trust, and long-term impact. When teams inflate story points or avoid real work to protect their “stats,” you’re not tracking progress—you’re tracking dysfunction.

Force multiplier insight:
Scrum Masters who protect velocity from misuse empower teams to focus on value, not vanity metrics.

Takeaway:
Velocity is a forecast tool—not a scoreboard. Use it to plan, not to pressure.

Myth: Agile means no planning.

Why this is wrong:
Agile doesn’t reject planning—it demands better, more adaptive planning. The myth usually comes from people who misunderstand flexibility as chaos or see story points as a substitute for real thought.

What’s actually true:

• Agile plans early, often, and incrementally.

• Roadmaps, backlogs, sprint goals, and reviews are all part of intentional planning.

• Agile shifts planning from “guess once, defend forever” to “learn fast, adjust often.”

Why this matters:
Teams that skip planning under the Agile banner end up with churn, misalignment, and half-baked outcomes. Planning isn't the problem—bad planning is.

Force multiplier insight:
Scrum Masters who coach effective planning cycles multiply clarity, confidence, and delivery across their teams.

Takeaway:
Agile isn’t anti-planning—it’s anti-wasteful planning. Trade static roadmaps for evolving clarity.

We talk a lot about psychological safety—and for good reason. Teams need trust to take risks, speak up, and grow. But here’s the uncomfortable truth:

Too much psychological safety can make your team soft.

Yes, you read that right.

The Problem: Comfort Without Accountability

When psychological safety becomes the only priority, teams start avoiding conflict, sugarcoating feedback, and tolerating mediocrity in the name of “being nice.”

You get:

• Weak retrospectives with no real tension

• Low performers hiding in the shadows

• Leaders afraid to challenge or confront

• Teams that confuse agreement with alignment

Safety without standards is just comfort. And comfort doesn’t drive performance.

What Healthy Teams Really Need: Constructive Pressure

The best teams strike a balance:

• Enough safety to speak honestly

• Enough challenge to grow and deliver

They know it's okay to disagree. They call out missed commitments. They push each other to raise the bar—without fear, but also without fluff.

This isn’t about being harsh. It’s about being real.

Build Strength, Not Fragility

If you want a team that can thrive in chaos, ship real value, and evolve fast, don’t just protect them—pressure-test them.

• Ask hard questions

• Give direct feedback

• Set a high bar and hold the line

Because psychological safety isn’t about shielding your team from discomfort. It’s about equipping them to face it and grow stronger.

Bottom line:
Psychological safety should be a launchpad, not a couch. Make your team resilient, not just comfortable.