BONUS Archives - Scrum Master Toolbox Podcast

BONUS: Why Software Projects Fail When Everyone Keeps Quiet

Software projects rarely fail because no one noticed the problem. More often, people see the missing database, the wrong assumptions, the broken process, or the weak product ownership, but the organization has trained them to stay quiet. In this BONUS episode, Mark Stringer, author of Delivering the Impossible, helps us understand how Scrum Masters can make reality visible again.

The Problem Of Intention In Software Projects

“You’ve got here a problem of intention, and you can’t fix that by coming up with new, more magical marks on the page.”

Mark starts with a story from the mid-1990s, before Agile was a common word in software teams. In a software development course, he heard the familiar promise: if only requirements could be captured with the right notation, the project would go correctly. His reaction was different. Software is not only a problem of documentation or process, it is a problem of translating intent into reality. That gap between marks on a page and what people actually need is where many projects begin to drift.

Point Of View Can Make Smart People Miss Reality

“If we see things in the wrong way, then point of view can take 80 IQ points off us.”

Mark uses Alan Kay’s idea that point of view is worth 80 IQ points to explain why good people can still make poor project decisions. A methodology can help, but only if it helps the team see what is actually happening. When the model becomes more important than reality, teams start defending the plan instead of learning from the system they are trying to change. Scrum Masters can help by asking what the current point of view hides, not only what it explains.

The Swamp: Why Project Complexity Is Not On The Diagram

“The fastest way between two points in a real organization is not necessarily a straight line.”

In one banking project, Mark found two realities that had not survived the diagrams. First, a transaction database shown on every architecture diagram did not exist. Second, after six months of requirements work and several million pounds spent, a simple show and tell revealed that the design was organized around accounts when stakeholders needed it organized around people. The point was not that the team had failed to write enough requirements. The point was that the real environment was a swamp of legacy systems, power shifts, competing groups, regulations, users, and assumptions. You only discover that swamp by starting, showing real work, and letting stakeholders react.

Agreed Activity: When The Rituals Keep Going But The Project Is Already Lost

“Everybody knows why the project’s failing. It’s not a mystery at all.”

Mark calls one common failure mode “agreed activity.” The team keeps attending standups, planning meetings, status reviews, and retrospectives, even when people privately know the project is not going anywhere. Often they have tried to raise the real issue before and were punished for it. After that, silence becomes rational. The organization keeps reporting activity, expenditure, and compliance with the process, while the real blockers stay untouched. For Scrum Masters, this is a warning: ceremonies are useful only when they let reality enter the conversation.

Product Ownership, Bad News, And The Message Leaders Send

“The message that the development team hears is: don’t rock the boat, just keep taking the money.”

The Product Owner role can help break agreed activity, but only if the person has enough authority to make decisions and enough proximity to the team to learn. Mark describes two common anti-patterns: appointing someone junior who can be pushed around, or appointing someone so senior they have no time for the work. Worse, when someone points out a fundamental problem and gets metaphorically shot, the team learns the real rule: stay quiet. Leaders may think they are asking for positivity or commitment, but the team hears permission to cut corners, hide bad news, and treat spending as progress.

Make Scrum A Hypothesis Testing Framework Again

“That kind of unexpected feedback, that’s the hope. That’s the machine working.”

Mark’s practical advice is to keep the cadence, but make the meetings real. A show and tell should expose assumptions. A retrospective should make uncomfortable feedback usable. Scrum works best when it is treated as an empirical, hypothesis-testing framework, not a list of meetings to implement. Mark also points to user research as a way to extend learning back into the environment. Teams cannot guess how users will react, which buttons they will press, what they will ignore, or what market and organizational changes are shaping the work. They have to test, learn, and adjust.

About Mark Stringer

Mark Stringer is the author of Delivering the Impossible, a 2026 Apress book on better ways of seeing software project management. He has spent 30 years in software delivery as a developer, application researcher, and project manager, working with IBM, Xerox, and Cambridge University.

You can link with Mark Stringer on LinkedIn and follow Mark’s writing at markstringer.github.io. You can find Delivering the Impossible on Amazon and Springer.

5th September 2026 at 10:05 CET
BONUS Why Software Projects Fail When Everyone Keeps Quiet With Mark Stringer

BONUS: How Scrum Masters Turn AI Into a Thinking Partner, Not a Magic Answer Box With Dave Westgarth

Everybody talks about AI in theory. In this BONUS episode, Dave Westgarth talks about it in practice — the boring, everyday ways a Scrum Master and Agile Coach actually puts AI to work. From t-shirt sizing to sprint reports to a self-coded Monte Carlo forecaster, Dave shares what works, what doesn’t, and the one mindset shift that separates people who get value from AI from those who just generate more noise.

From “Magic Answer Box” to Personalised Partner

“Instead of taking it as a magic answer box, using it as a personalised partner to work through problems, look at your ideas, and really hold them in the cold light of day before proposing things.”

Dave came into agile from a development background, moved through project delivery, and had already worked at AI and ML companies long before ChatGPT made the technology personal and accessible. Like most people, he first met these tools as a “magic answer box” — ask a question, get an answer, run with it.

The real shift came when he stopped optimizing for output and started using AI to drive better outcomes: ping the model, get a response, then interrogate it, refine the thinking, and go around again. The value isn’t the first answer. It’s the conversation that sharpens your own reasoning.

These Tools Aren’t Neutral — So Corner Them Into Being a Critic

“If you ask it to be punishing, negative, and brutal, it gives you a lot more relevant feedback.”

One of Dave’s sharpest points: AI tools are not neutral guides. Because of their system prompts and the incentives baked in by the providers, they’re relentlessly positive — they want to affirm you and keep you around, a little like social media.

That makes them weak for anything where you need honest pushback: personas, user stories, feedback on ideas. Dave’s fix is to flip it on its head. Rather than asking “is this any good?” (which reliably earns an “8 out of 10, but to make it a 10…”), he tells the model to be as harsh and brutal as it can and really try to punish the idea. You don’t want a partner that always agrees with you — you want one that pinpoints the areas you haven’t thought about.

The First Real Time-Saver: Reports, and the Themes You Missed

“Are there any themes that have emerged over the last 4 weeks that I might have missed in this latest deck?”

The first thing that stopped feeling like a party trick was the one we all know: project documentation and reporting — sprint reports, status updates, review decks. Instead of letting AI invent the structure, Dave feeds it his own structure plus Teams recordings, notes, and existing docs, and lets it populate the format he already uses.

The trick that goes a level deeper: after several sprints, feed all the AI-assisted reports back in and ask what themes have emerged across the last four weeks that this latest deck might have missed. Again, it stops being an answer box and becomes a partner and critic.

AI Is Part of the Job Now — Like Spreadsheets Once Were

“The way to get ahead now is figure out how to use it as effectively as you can in your role.”

Dave sees the early resistance movement against AI as a false economy. For delivery professionals — project managers, Scrum Masters, agile coaches — knowing how to use these tools well is fast becoming a core expectation, not a nice-to-have.

Vasco draws the parallel to spreadsheets: once dismissed as too complicated and “not my kind of thing,” until people started building real forecasting and capacity models with them and the work changed. AI is on the same arc — still a little mystical today, genuinely useful tomorrow, and eventually just another tool in the box.

A Week With AI in the Loop

“The power that these prompt-to-product tools give you to create these hyper-personalized tools that make you more effective is, in a lot of ways, magic.”

Dave walked through what his week actually looks like with AI in the loop:

- Monday primer: a scheduled ChatGPT task emails him a scene-set every Monday — last week’s plan and top priorities — so he isn’t spending the first half hour reconstructing where things stood.
- Priority calls: which items are the toughest, where the quick wins are, where he can get early traction, and where risks might be emerging that he can squash early.
- Everyday comms: drafting the bones of emails, pings, and project updates so he spends almost no time formatting.
- Prompt-to-product tools: using Base44, Lovable, and Replit to build his own tools — including a Monte Carlo forecaster that takes his team’s sprint throughput and projects the remaining backlog, replacing an ugly spreadsheet with a clean web app. He also builds AI-powered widgets in Miro for retrospectives, mood check-ins, and planning poker.

The theme running through all of it: hyper-personalized tooling, shaped by your team and your own skills, rather than one-size-fits-all software.

The Myth That AI Makes Scrum Masters Worse

“I can’t see any role of a knowledge worker where having an LLM at your disposal makes you less capable, less knowledgeable, less skilled than someone that doesn’t.”

Dave sees the same adoption spectrum among developers and Scrum Masters — from “I’ll never touch it” to “I’ll never write code by hand again.” And he pushes back hard on an emerging prejudice that echoes the old “technical Scrum Masters are worse” debate: the idea that Scrum Masters who use AI are somehow weaker.

Used well, AI lets you elevate your strengths and cover your gaps — a people-centered Scrum Master can become far more technical, and a technical one far more people-centered, each with a trusted teaching guide right there. The key competency isn’t avoidance; it’s discernment about when to reach for the tool and when not to.

From More Output to Better Outcomes

“The bottleneck has never really been typing code. The bottleneck has been understanding the problems and the customers well enough to define a solution that fixes them.”

Dave’s clearest reframe: AI is driving the price of output down. When volume is easy — more features, more emails, more documents on demand — churning out more of it stops being a differentiator, because everyone can do it. What matters is deciding which problems are worth solving and finding the most effective solution.

Experienced agile professionals have always known the real bottleneck was understanding the customer well enough to define the right solution, not the typing. AI just exposes that in a much starker way: there’s nowhere left to hide behind sheer volume.

What to Pay Attention To — and a Monday Experiment

“It can do a lot of that manual, low-thinking, high-effort work to free you up to do more of the really impactful stuff.”

For Scrum Masters being told to “adopt AI,” Dave’s advice is to let it take the joyless work — the end-of-sprint collateral, the Jira monitoring, the reports and charts — so you can spend your time on the coaching, the strategic thinking, and the organizational-level impact that’s harder to reach when you’re buried in tactical chores.

His concrete Monday-morning experiment: take the two or three prioritized actions from your next retrospective, bring them to ChatGPT or Claude, and ask, “which of these could you really help me with, and how could you help me move the needle?” Start a conversation. You don’t have to accept its answers — the point is to sharpen your own thinking about where you can add the most value next sprint.

Developing “Taste” With AI

“One element of taste is being able to judge it fairly harshly — getting through the beige as quickly as you can to find the little nuggets and gems.”

Both Dave and Vasco land on the same skill for the year ahead: taste. These tools produce a lot of text, and not all of it is useful. Vasco shares his own aha moment — asking for ideas, getting the obvious ones, then repeating “give me more, don’t repeat any” until the model finally surfaced something genuinely unexpected. That simple move turns AI into an engine for exploring the solution space until something clicks. The competency to build is the ability to move through the beige quickly and recognize the gems that materially change what you do next.

Recommended Resources

In this episode, Dave has the following recommendations for those wanting to learn, and take advantage of AI at work:

- https://scrum-master-toolbox.org/, The podcast that helps you learn faster! 😉
- Co-intelligence by Ethan Mollick
- Lenny’s podcast on YouTube: https://www.youtube.com/@LennysPodcast

About Dave Westgarth

Dave Westgarth is a product and Agile practitioner exploring how AI transforms product development, experimentation, and team workflows. He shares practical insights on leveraging tools to accelerate value delivery and innovation.

You can link with Dave Westgarth on LinkedIn and find him in the Miro community and on Miroverse.

BONUS: How Scrum Masters Can Use AI Without Becoming the Human API, With Fred Deichler

AI is already changing the practical, everyday work of Scrum Masters and Agile Coaches. In this BONUS episode, Vasco talks with Fred Deichler about moving from curiosity to real AI-supported workflows: finding team signals faster, preparing better conversations, keeping documentation in sync, and staying focused on outcomes instead of just producing more output.

From Automation to an AI Sparring Partner

“I have this partner I can work with to help me ideate things.”

Fred’s journey into AI started before the current AI wave, with automation in Jira and the practical need to surface bottlenecks without manually watching every board. The turning point came when ChatGPT stopped feeling like a search box and started acting like a thinking partner.

Faced with a team being pushed toward multiple sprint goals, Fred dumped the context into AI and asked for three to five options instead of one “right answer.” That shift helped him move from a deterministic mindset into a problem-solving mindset, using AI to explore options, challenge his own assumptions, and prepare a better conversation with the team.

The Monday Morning AI Context Builder

“It instantly sets that context for me. It sets that tone for the whole week.”

Fred describes his weekly workflow as a very practical use of AI: on Monday morning, he opens Cursor and works with his own AI harness, Atlas. Atlas is built from markdown files containing persona, skills, history, meeting transcripts, notes, and Jira data. When Fred says “good morning,” the system pulls the most relevant signals forward: aging work items, backlog health, sprint goals, and where the next team conversation should focus. Instead of starting the week by hunting for data, Fred starts with questions he can bring into the first stand-up: what is stuck, what needs refinement, and what risk is already visible?

Making Flow Metrics Visible Inside Jira

“If you’re on a page, what do you hope you could learn without asking?”

Beyond using AI as a thinking partner, Fred used AI to build a Chrome extension that surfaces useful Jira insights directly where the team already works. On the active sprint board, it shows work in progress, aging items, sprint goals, and sprint changes. In the backlog, it exposes backlog health and epic health. On the sprint report page, it adds cycle time per item so the retrospective can move from generic discussion to concrete learning. The point is not to shame the team with metrics. The point is to make the right conversation easier to start: what caused this item to take seven days, what blocked it, and what do we want to learn from that?

AI as Extra Eyes and Ears for Team Conversations

“It helps make sure that we don’t lose sight of these things I can bring back to the team.”

Fred also uses AI agents to review meeting transcripts and look for patterns that are easy to miss in the flow of daily work. The system can notice hesitation, unresolved topics, or a requirement problem that was mentioned once and never followed up. For retrospectives, Fred’s Atlas setup can review sprint transcripts around day nine of the sprint and suggest themes for the next retro. It can even generate prompts for a visual retrospective board in Copilot or a Miro board from a prompt. This helps Fred avoid relying only on recency bias and creates a better starting point for the conversation the team actually needs.

Keep the Human in the Loop, Especially for Outcomes

“It’s not about building a faster hammer. It’s about identifying the outcome you’re going for.”

A major warning in the episode is that AI can make Scrum Masters faster at producing more of the same: more notes, more summaries, more documents, more reports. Fred argues that the useful question is not “can we automate this exact process?” but “what outcome are we trying to achieve?” In a Jira-to-Azure DevOps migration, for example, the goal was not to reproduce the current time-tracking process perfectly. The goal was to provide the information accounting needed. That outcome focus keeps the human accountable for direction, judgment, and value, while AI helps explore better ways to get there.

The SPOT Framework for Finding AI Opportunities

“If it meets three or four of those, this is a great opportunity for an automation to free me up to do that more human-centric work.”

Fred uses a simple filter, the SPOT framework, to decide what AI should help with and what should remain human-led. A task is a good candidate when it is simple, predictable, observable, and tedious. Simple means it requires low human judgment and could be explained on an index card. Predictable means it happens repeatedly, either on a schedule or triggered by an event. Observable means the needed data is available to the agent and not locked away in someone’s head or behind policy. Tedious means it consumes energy without adding much human value. When a task matches most of those criteria, Fred looks for ways AI can handle the toil while he stays focused on facilitation, coaching, and decision-making.

A Small Experiment Scrum Masters Can Try Tomorrow

“If a Scrum Master finds himself operating as, like, I’m moving data from point A to point B, that is a great opportunity to say, how might we do this?”

Fred’s concrete advice is to start by noticing where you have become the “human API”: moving data between tools, updating spreadsheets, copying information into reports, or keeping documents manually aligned with reality. Write down one tedious workflow and ask your approved work AI, “How might we automatically populate this, while keeping me in the loop?” Vasco adds a useful ideation tip: if the first five ideas are not good enough, ask for five more without repetition, then five more again. The goal is not to hand over accountability. The goal is to discover what might be possible and choose one safe, small experiment.

Resources for Scrum Masters Exploring AI

“It’s all about building up your own idea of what’s possible to start those how-might-we conversations.”

For listeners who want to keep learning, Fred recommends The AI Daily Brief as a way to stay current with what is happening in AI, and Jack Roberts’ YouTube channel for practical ideas around personal AI and agent-based workflows.

About Fred Deichler

For over two decades, Fred has been a technology leader, who has been intuitively following the Scrum values and Agile principles even before discovering them. He has successfully led multiple teams on their Agile journeys, emphasizing the importance of a harmonious balance between people, processes, and tools, and continuously striving for improvement. For Fred, personal growth is as crucial as professional development.

You can link with Fred Deichler on LinkedIn and connect with Fred Deichler at Triforce Agility.

BONUS: When Burnout Looks Like Productivity—The Hidden Risk to Your Team’s Innovation Capacity

In this BONUS episode, Alison Campbell, CEO of unBurnt, and researcher at Bentley University shares the research that reframes burnout as a measurable threat to a team’s ability to innovate. We learn why your most productive people may be your biggest innovation risk, how to spot capacity draining out of a team before the output drops, and where Scrum Masters have the leverage to protect the one thing that keeps teams building: the space to think.

From the ER to the Research

“I kept normalizing the stress, the exhaustion, eventually the stomach aches as, well, this is just the price of entry. This is part of being a busy, full-time executive and working mom.”

Alison spent nearly twenty years in corporate roles—moving from finance to e-commerce to HR tech, with analytics as the through line and a love for the building phase inside companies. The pandemic was the turning point. With two young kids at home and a global team to hold together, she pushed through eighteen months of warning signs she had normalized, until severe stomach pain landed her in the emergency room needing surgery.

That was the stop moment.

What started as private shame—the feeling that she alone had failed while everyone else “had it all figured out”—became a research question the moment she started talking about it and heard the same story mirrored back from colleague after colleague. This wasn’t one exhausted mom at a hard moment. It was a design and systems problem worth studying.

When Burnout Looks Like Productivity

“Even when that innovative work behavior was high, when burnout was high, that segment of our sample had the lowest innovation capacity of the entire group we surveyed.” Continue reading BONUS: When Burnout Looks Like Productivity—The Hidden Risk to Your Team’s Innovation Capacity

BONUS: Why Observability, Not Capability, Is the Next AI Frontier

We’ve spent years asking what AI can do. But the next frontier isn’t more capability—it’s something far less glamorous and far more dangerous if we get it wrong. In this episode, Ran Aroussi shares why observability, transparency, and governance may be the difference between AI that empowers humans and AI that quietly drifts out of alignment.

The Gap Between Demos and Deployable Systems

“I’ve noticed that I watched well-designed agents make perfectly reasonable decisions based on their training, but in a context where the decision was catastrophically wrong. And there was really no way of knowing what had happened until the damage was already there.”

Ran’s journey from building algorithmic trading systems to creating MUXI, an open framework for production-ready AI agents, revealed a fundamental truth: the skills needed to build impressive AI demos are completely different from those needed to deploy reliable systems at scale. Coming from the EdTech space where he handled billions of ad impressions daily and over a million concurrent users, Ran brings a perspective shaped by real-world production demands.

The moment of realization came when he saw that the non-deterministic nature of AI meant that traditional software engineering approaches simply don’t apply. While traditional bugs are reproducible, AI systems can produce different results from identical inputs—and that changes everything about how we need to approach deployment.

Why Leaders Misunderstand Production AI

“When you chat with ChatGPT, you go there and it pretty much works all the time for you. But when you deploy a system in production, you have users with unimaginable different use cases, different problems, and different ways of phrasing themselves.” Continue reading BONUS: Why Observability, Not Capability, Is the Next AI Frontier