AI is often framed as a technology rollout, but Melissa Reeve makes a different case: organizations that already know how to learn, adapt, and improve are better prepared for AI. In this BONUS episode, we connect Lean, Agile, DevOps, and AI-native work, and explore why Scrum Masters may be closer to the center of AI adoption than they think.
From Toyota Production System to AI-Native Work
“I didn’t really have words for what would later be my career. I didn’t know about systems thinking. I didn’t know about this thing called Agile.”
Melissa traces the through-line from studying the Toyota Production System in Tokyo, to early Agile marketing, to developing intellectual property at Scaled Agile, and finally to AI. Her point is that Lean, Agile, and AI-native work are not separate conversations. They all depend on sensing what is happening, shortening feedback loops, learning from reality, and improving the system instead of only optimizing individual tasks.
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 REALLY costing us.
Organizations Are Conversations
“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.
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.
In this BONUS episode, Roman Nikolaev challenges one of the most deeply held beliefs in the agile world: that more collaboration is always better. As Head of Technology at Cambri, Roman has watched teams burn their best hours in meetings and hand offs that create the feeling of productivity without the outcomes. He shares practical tools — from the vacation test to RFC processes — that help teams find the minimum viable level of collaboration.
From Senior Engineer to Accidental Manager
“I kind of accidentally ended up in management. I didn’t want to lead anyone, I wanted to be just a senior engineer doing my stuff. But somehow, four months in the job, I was already leading a team, and then one year after, I was head of technology.”
Roman’s career in engineering goes back to the early 2000s. When he changed jobs during COVID, he specifically didn’t want a management role — he wanted to code. But within months he was leading a team, and within a year he was running the entire technical organization at Cambri.
That unexpected shift from hands-on engineering to leading teams gave him a front-row seat to how collaboration actually works — and how often it doesn’t. What he noticed was that the most important differentiator for technical teams isn’t technical knowledge — it’s communication, and the tax you pay when communication goes wrong.
Clarke Ching is “The Bottleneck Guy” — and he just spotted the bottleneck that AI is about to create in every software organization. It’s not in the code. It’s inside the heads of the people who decide what gets built. In this conversation, Vasco and Clarke unpack why speeding up developers with AI tools pushes the real constraint upstream — onto product managers, designers, and leaders — and what to do before cognitive overload crushes the people your organization depends on most.
Every Business Has a Bottleneck — Most Are in the Wrong Place
“Every single client I have is a detective puzzle. We’re looking for this quiet killer sitting inside their business, siphoning off money. And if you look at them without the idea of going ‘where’s the bottleneck?’ — you mistake the busyness for productivity.”
Clarke approaches Theory of Constraints like a detective story, not a physics lecture. Every business has a bottleneck — the narrowest point that chokes throughput. The question isn’t whether you have one, it’s whether it’s in the right place. In software development, Clarke argues, the bottleneck should almost always be the developers. Not because they’re slow, but because they’re the pacing resource — like the aircraft carrier in a naval fleet that sets the speed for everything else. When developers are the bottleneck, the people upstream (product managers, designers, architects) have time to curate high-quality, high-value inputs. The people downstream (testers, ops) can deliver fast feedback. Everything flows. But when the bottleneck drifts somewhere else — and nobody notices — everyone gets busy, nothing flows, and the organization mistakes that busyness for productivity. Clarke’s latest book, The Speed Book, lays out how to find where your bottleneck actually is and move it to where it belongs.
AI Just Moved the Bottleneck — And Nobody’s Talking About It
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Internal Conference
Checklist
Internal Conference
Checklist
Download a detailed How-To to help measure success for your team
Motivate your team with the right metrics, and the right way to visualize and track them. Marcus presents a detailed How-To document based on his experience at The Bungsu Hospital
Download a detailed How-To to help measure success for your team
Read about Visualization and
TRANSFORM
The way your team works
A moving story of how work at the Bungsu Hospital was transformed by a simple tool that you can use to help your team.
Read about Visualization and
TRANSFORM
The way your team works
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners. Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners. Access three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners.
Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
FREE! Audiobook Chapters: Overcome Team Resistance and Gain Leadership Buy-In
Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Your FREE ticket is on the way!
Check your inbox for details.
Email us at
ProductOwnerSummit.org if you have questions
Check Your Inbox For Details
Email us if you have questions:
ProductOwnerSummit@oikosofy.com
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.