Scrum Master Toolbox Podcast: Agile storytelling from the trenches

BONUS: From AI Curiosity to Practical Project Tools With William Davis
AI becomes useful when it moves from generic answers into the daily work of solving real problems. In this BONUS episode, William Davis shares how he started building his own AI-assisted project management tools, what went wrong when the code grew too fast, and how Scrum Masters can use AI more carefully at individual, team, and project levels.
When AI Stops Being a Curiosity
"I really need to get a handle on how to productively use AI in my job."
 
William's shift started with a familiar problem: release plans are full of uncertainty, but stakeholders still need to understand what might happen and when. Instead of handcrafting uncertain delivery ranges in Excel, William used AI to build a desktop application that created probabilistic Gantt charts. In his work, these were not traditional command-and-control schedules. They were release plans that showed stakeholders a realistic range of possible delivery dates, making uncertainty visible instead of hiding it behind a false promise.
The Euphoria and the Crash
"Anybody can prompt an app into existence, but if you want an app that is actually enterprise-worthy, it does take a little bit of software engineering knowledge to know what questions to ask."
 
The first experience felt almost magical: ask questions, get code, assemble the pieces, and see a working application appear. But the magic faded when William kept extending the tool and the code started breaking in familiar ways. The AI forgot previous decisions, repeated mistakes, and produced a growing mass of tangled code. The lesson was direct: AI can move fast, but it still needs architecture, tests, and software engineering judgment. Without that, teams can build quickly and still end up with something hard to use, hard to maintain, and hard to trust.
AI as a Partner Inside the Tool
"The collaboration has a third partner, the AI."
 
William's work expanded from one application to several tools for forecasting, story mapping, release planning, and budgeting. The more interesting change was not only using AI to build tools, but building tools that could connect to AI while people used them. Through Model Context Protocol, William's tools can work with an LLM partner to help teams turn rough product ideas, emails, and scattered artifacts into structured story maps. The team still edits, challenges, moves, splits, and reframes the result. AI helps create a first model faster, but the team keeps responsibility for meaning and decisions.
Security Starts With Where the Data Lives
"Start with the easy sell: I'm building a tool, and the data that I'm creating is stored locally on your employer-managed device."
 
William is clear that AI adoption in organizations cannot ignore infrastructure and cybersecurity concerns. His first approval path came from designing tools that default to local storage in the browser, on an employer-owned and managed device. That made experimentation easier because sensitive project data did not need to leave the company environment. For teams using MCP or company AI platforms, the same question matters: where is the data going, who governs it, and what agreements protect it from being used for model training? Scrum Masters and software leaders need to treat security as part of the coaching conversation, not as an afterthought.
Better Questions, Earlier in the Work
"My goal is to solve the problems that I have at the moment that I'm having them."
 
For William, AI changed the work by removing delays between seeing a problem and trying a solution. A release forecast that once took 30 minutes to handcraft can now be updated in a few minutes during the team conversation. In a cloud ERP evaluation, AI allowed him to ask vendor-specific timeline questions much earlier than before. Instead of waiting deep into an RFP process to discover how different solutions would change the implementation plan, he could compare likely timelines upfront and make the trade-offs visible sooner.
Go Slow to Go Fast With AI
"Ask three different sessions the same question."
 
One of William's strongest warnings is that a single LLM answer can feel more certain than it really is. LLMs are probabilistic, and the same prompt can produce different answers across models or sessions. His workaround is to slow down the design step: ask multiple sessions or models to analyze the same problem, then use an orchestrator session to compare the answers and improve the design. For architecture questions, he may use Claude, ChatGPT, Grok, and Gemini. For smaller product improvements, he uses multiple sessions inside one LLM ecosystem. This is not a return to big upfront design. It is short-cycle research, planning, and implementation, repeated in small increments.
A Practical First Step for Scrum Masters
"Rather than just read about how to use AI, just start using it."
 
William's practical advice is to choose one real problem and ask your LLM how to approach it. If you are not familiar with MCP, start there: ask your preferred model how to connect to a tool through MCP, and experiment with a low-risk use case. William also invites listeners to try the free tools at SPERT Suite, where the default local mode keeps data on your own device. His broader point is simple: AI becomes useful when it is connected to a specific work problem, a clear feedback loop, and a human who still owns the judgment.
About William Davis
William Davis is a seasoned IT professional with four decades of experience as a software developer, project manager, and agile advocate. A certified Scrum expert and PMP, he promotes personal and organizational agility, delivers customized training, and mentors agile practitioners. Creator of Statistical PERT® and SPERT® Suite, William innovates with free, AI-powered project management tools for today's agile teams.
 
You can link with William Davis on LinkedIn and explore William's free tools at SPERT Suite.

BONUS: How Scrum Masters Can Use AI Without Losing the Human in the Loop
AI makes it easier than ever to build software, prototypes, courses, and coaching tools. In this BONUS episode, Mike Lyons and Greg Pfister share what that speed changes for Scrum Masters, why product judgment becomes more important, and how coaches can start using AI without outsourcing the conversations their teams still need.
When AI Stops Being a Curiosity and Starts Saving Real Time
"It's not that the work is wrong or not needed, it is needed. That's an important step. Retrospectives are critical."
 
Greg's first practical AI moment came while trying to build an "Ask Mike" capability for self-paced courses. After a frustrating outsourcing attempt, he started using ChatGPT to help him rebuild the tool himself, eventually moving into Cursor, Claude Code, and the Superpowers plugin for Claude Code. Mike's moment was less technical: using AI inside Mural to affinity-map retrospective notes. The lesson for Scrum Masters is not that AI removes the work, but that it can remove enough friction to let facilitators spend more time on judgment, listening, and follow-through.
The Bottleneck Moves From Building Fast to Building the Right Thing
"The cost to produce prototypes for software engineering is approaching zero."
 
Mike and Greg argue that AI does not create the "wrong feature" problem, but it makes the problem much easier to multiply. If a prototype can appear before lunch, the old excuses disappear. Teams still need to ask whether the customer problem is real, whether the payoff matters, whether there is proof from users or data, and whether this work deserves priority now. For Scrum Masters and Agile coaches, this is a clear invitation to help Product Owners slow down the decision before accelerating the delivery.
Building AskMe With AI as the Engineering Partner
"I'm really playing product manager. That's really what I'm doing."
 
Greg describes AskMe as an AI-enabled coaching tool embedded into training courses. Instead of asking learners to pass obvious multiple-choice quizzes, AskMe asks them to apply what they learned to their own context, then reflects back practical coaching based on the course material, instructor context, and learner profile. In their own product development, Greg uses AI as an engineering partner while Mike keeps asking the product question: should we build it? Their 4P lens is simple: problem, payoff, proof, and priority.
The Scrum Master Role Becomes More Important, Not Less
"Don't just outsource your brain, your decision making power."
 
When leaders push teams to "adopt AI," Mike warns Scrum Masters not to let the tool become the decision maker. AI can cluster retrospective notes, summarize long threads, propose learning plans, or help prepare for a hard conversation, but the human still needs to inspect the output and understand the consequences. Greg adds the practical security angle: teams must be careful about what they paste into AI systems, especially personal, customer, or sensitive company information.
Start Small: Context, Role Play, and Shared Learning
"Context is king when you're talking with your AI."
 
Greg suggests starting with basic AI training, then practicing with small workflow improvements: prioritizing work, summarizing material, or drafting communication that the Scrum Master then edits. Mike's practical starter experiment is role play: describe a difficult team situation without names, ask the AI to act as the other person, and practice the one-on-one conversation. Vasco adds a simple working habit: keep a running context file with meeting notes, team insights, worries, decisions, and open questions, then use that context when asking AI for help.
Resources for Scrum Masters Learning AI
"Let AI help you get smart about AI."
 
Mike recommends the PMI AI in Project Management learning resources and the 37signals Rework podcast for pragmatic thinking about how AI fits into work. Greg recommends learning directly from the AI tool providers, exploring how to configure projects and context, and reading Marty Cagan's Inspired to strengthen the product judgment that becomes more important when teams can build faster.
About Mike Lyons and Greg Pfister
Mike Lyons and Greg Pfister are the team behind KaiRise, where they've used AI to build new products, including AskMe, an AI coaching tool, and to create their most recent certified Product Management training course end-to-end.
 
Greg Pfister works with Mike at KaiRise on AI-enabled learning products, including AskMe and their certified Product Management training course.
 
You can link with Mike Lyons and Greg Pfister on LinkedIn. You can find KaiRise and AskMe at kairise.com.

BONUS: The Hidden Dangers of AI at Work With Ari-Pekka Skarp
AI is usually sold as a productivity tool, but Ari-Pekka Skarp argues that the real story is what it does to the conversations, skills, and purpose that hold teams together. In this BONUS episode, Ari-Pekka explores why organizations are rushing to use AI "as efficiently as possible" without defining what efficiency means, and what that rush is quietly costing us.
Organizations Are Conversations
"The organizations are actually conversations, conversational patterns between people."
 
Ari-Pekka's path from software engineering in 1999 to psychology, psychotherapy, and change leadership was driven by one thread: how the mind works, both individually and socially. Meeting Ralph Stacey, Esko Kilpi, and Douglas Griffin at Nokia changed how he saw organizations. Instead of a machine made of parts, an organization is a living pattern of conversations — people responding to each other's gestures, again and again. George Mead added the idea that the human mind itself is not individual but relational. This matters for AI because a large language model is a new kind of player in those conversations, not just a tool that moves data between them.
The Efficiency Fetish
"It's like how much people are pressing the acceleration pedal in the car. It doesn't tell anything where the car is going."
 
Many organizations are trying to use AI "as efficiently as possible," but Ari-Pekka points out that few have defined what efficiency means. What he sees instead is measurement of AI usage itself — how many people are prompting, how many tokens are flowing. He calls this tokenmaxxing. The car metaphor is the key: pressing the accelerator harder says nothing about direction, and going fast in the wrong direction is more costly than going slow. Efficiency only has meaning against a purpose, and purpose is itself a conversational achievement — something a team has to talk its way into.
De-Skilling Is the Hidden Cost
"If there's nobody in the room who could review what AI has produced and say whether it's correct or not, it's not an AI strategy. It's a liability."
 
The risk Ari-Pekka worries about most is de-skilling. When we offload cognitive work to AI, we lose the friction that builds learning. There is neurological evidence that people who rely heavily on AI do not develop the same brain structures as those who work through challenges manually. Some skills are fine to lose — nobody needs machine code anymore — but the ability to review and judge AI output is critical, and it is exactly what erodes when we skip the slow work. The result is a double bind: senior experts burn out under the review burden of fast-produced AI output, while juniors never get the time to build the expertise they would need to review it.
We Need Speed Limits for AI
"We can't optimize individual going as fast as possible... we need a collective... boundaries for individuals."
 
Ari-Pekka reaches for a historical analogy. Our biological rate of processing information is roughly ten bits per second, and it is not going to change. When we only had horses, we did not need speed limits. When we built cars that could go 200 kilometers per hour, we had to invent rules and boundaries to protect the system. AI is the same: we have reached a threshold where optimizing individual output — more code, more stories, more messages — can damage the whole organization. The control mechanism Ari-Pekka proposes is cognitive friction, deliberately added back into the system so that speed serves the system rather than breaking it.
The Tokenization of Work
"It's very easy to lose the purpose where you are going if you are only doing fragments of work."
 
Ari-Pekka's article The Tokenization of Work describes what happens when the unit of work is no longer a job, a profession, or even a task. Digital tools make it easy to fragment work into tiny pieces and spread them across AI agents, and in the process the boundaries that gave work its meaning vanish. Purpose is what protects us from burnout: with a clear purpose, people can do very demanding work without burning out, because the work feeds them. Without purpose, exhaustion arrives fast. For Scrum Masters, this means grounding the work in why it matters is more important now, not less.
AI Is an Echo Chamber, Not a Mirror
"The AI is more kind of an echo chamber in a sense that it doesn't push back so much."
 
Ari-Pekka compares AI to George Mead's "generalized other" — the internalized sense of how others see us. AI can play that role, but with a dangerous twist: it is programmed to be agreeable, so it behaves more like an echo chamber than a mirror. Real people push back, point out mistakes, and keep disagreeing. That friction is where learning, competence, and self-awareness grow. Ari-Pekka's practical move is to prompt AI for three different and conflicting perspectives rather than one, using it to go wider rather than only faster. It is not a perfect fix — the model still tries to merge them into one — but it is better than a single agreeable answer.
A Three-Second Pause
"Take a three-second pause... and just ask yourself, what are you doing?"
 
Ari-Pekka leaves listeners with a small challenge. A few times a day, when you are about to prompt an AI, pause for three seconds and ask what you are actually doing: are you seeking information, or seeking confirmation? Then consider whether it would be better to call a person and have a real conversation. It is a tiny practice, but it points at the whole episode's message: AI is not neutral infrastructure. It changes the conversations, the skills, and the purpose of work, and the people who notice that — Scrum Masters and Agile coaches especially — are the ones who can keep it from quietly reshaping their teams.
About Ari-Pekka Skarp
Ari-Pekka Skarp is a psychologist, psychotherapist, Lead Change Coach, organizational psychologist, and author. He wrote Mindfulness, mielenselkeys ja myötätunto, hosts Mielen laboratorio, and researches nondualism. His work connects psychology, complexity, Agile, and AI at work.
 
You can link with Ari-Pekka Skarp on LinkedIn. You can read Ari-Pekka's Finnish writing at tietoisuustaidot.com and his English blog at Fractal Sauna. You can also find Ari-Pekka's previous Scrum Master Toolbox Podcast episodes on his guest page.

Deborah Colombari: Product Owners Who Protect Focus and Enable Ownership
In this episode, we refer to INVEST criteria and Behavior Driven Development.
The Great Product Owner: Clear Outcomes, Strong Refinement, and Space for the Team
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"He doesn't say how. That allows the team to own the solution." - Deborah Colombari
 
Deborah describes a great Product Owner who came from project management, but learned to work deeply with upstream discovery and refinement. This PO uses INVEST criteria, Behavior Driven Development-style acceptance criteria, and explicit policies so that developers understand what needs to be done and why. He writes down expected outcomes at the epic and feature level, not only at the story level. Because he does not have a developer background, he depends on the tech lead, and Deborah sees that as a strength when the collaboration works. The PO brings business outcomes and clarity. The team brings technical options and owns the solution. That split creates room for trust.
 
Self-reflection Question: Does your Product Owner make the outcome clear while still leaving the solution to the team?
The Bad Product Owner: Adding Work Without Understanding the Consequences
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"He was doing whatever he wanted without thinking of the consequences." - Deborah Colombari
 
Deborah's Product Owner anti-pattern is a cross-team PO who accepted incoming requests and simply added them to the Sprint. There was no clear requirement discussion, no Definition of Done check, no Definition of Ready conversation, and no technical refinement with someone who could expose complexity. The PO treated every request as urgent, even when it was not, and told developers to stop their current work to pick up the new item. The result was more parallel work, broken Sprint Goals, less predictability, and a destabilized team system. Deborah eventually had to step partly into the Product Owner space to limit WIP and protect delivery. The lesson is blunt: Product Owners who ignore consequences turn priority into chaos.
 
Self-reflection Question: What is the cost of every "small urgent request" your team accepts mid-Sprint?
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Deborah Colombari
 
Deborah is an Enterprise Agile Coach with a decade of experience championing Agile principles across organizations. Passionate about collaboration and continuous improvement, Deborah genuinely loves what she does—empowering others to work smarter, deliver value, and thrive in dynamic environments.
 
You can link with Deborah Colombari on LinkedIn.

Deborah Colombari: Stable Agile Teams Make Delivery Predictable
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"When I have a stable team, I have reliable data." - Deborah Colombari
 
For Deborah, success as a Scrum Master comes down to one word: stability. A stable team communicates better, shares knowledge, avoids hero-driven delivery, and becomes predictable enough that the Scrum Master can use historical data instead of wishful thinking. Deborah connects stability with flow metrics and statistical thinking. When an expedite request appears, a stable team can look at its own history and forecast with a useful level of confidence. An unstable team, by contrast, creates silos, overloads key people, and turns every new request into a crisis. Vasco connects Deborah's answer to systems thinking and statistical process control: the team is part of a wider system, and its delivery capability reflects that system. The point is not to force the team to commit beyond what the system can support. The point is to observe the system, improve it, and use real data to forecast what is likely to happen.
 
Self-reflection Question: Do you know your team's delivery capability from evidence, or are you still depending on optimistic commitments?
Featured Retrospective Format for the Week: The 4Ls Retrospective
Deborah recommends the 4Ls retrospective: liked, learned, lacked, and longed for. She adds one practical extension: an action-items column. Deborah likes the 4Ls because the quadrants help the team see the same issue from different angles. Something the team longed for may connect to something they learned. Something they liked may expose what was previously missing. The action-items column matters because complaint is easy, but turning a complaint into a concrete experiment is harder. Deborah uses those actions to create or update team agreements, making the retrospective outcome last beyond the meeting.
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Deborah Colombari
 
Deborah is an Enterprise Agile Coach with a decade of experience championing Agile principles across organizations. Passionate about collaboration and continuous improvement, Deborah genuinely loves what she does—empowering others to work smarter, deliver value, and thrive in dynamic environments.
 
You can link with Deborah Colombari on LinkedIn.