Advertise on podcast: Definitely, Maybe Agile

AI can now produce output faster than most organizations can absorb it. Mik Kersten explains why the move from output to outcome has become a leadership job. Mik, author of Project to Product and his new book Output to Outcome, joins Peter and Dave to talk about what happens when coding stops being the bottleneck. For years, business teams fought to get their feature into the next plan because delivery capacity was scarce. With agents taking that constraint away, the bottleneck moves. It might be customer adoption, security reviews, budget, or how long it takes to get real feedback. Mik walks through the outcome loop, which connects strategy and budget to outputs and then to customer and business outcomes, and explains how to apply the theory of constraints to it. He also covers the outcome tree, a way of cascading company-level targets down to the value streams doing the work. Peter and Dave push on the hard parts: business leaders who can’t name their top outcome, B2B teams that wait months for usable feedback, and operating models that fall apart once the leader who championed them moves on. This week’s takeaways: When AI removes coding as the constraint, the bottleneck shows up somewhere else, so measure the whole loop from budget to customer outcome and go find it.If a team can’t connect its work to a company-level outcome, the strategy was never decomposed, and moving faster only makes that gap more obvious.Outcome ownership needs to sit with the teams closest to the work, with the business at the table, and the operating model has to outlast any single leader.Listen to the full episode at definitelymaybeagile.com  Subscribe so you never miss an episode.  Have a question or topic you’d like us to cover? Reach out at [email protected]

Spec-driven development with AI is getting a lot of attention. Peter and Dave ask when that structure actually helps you, and when it slows you down. They start with the AI SDLC white paper Anthropic recently published. It lays out a structured, spec-driven approach built for consistency. Peter sees it working best on large legacy systems, the kind with millions of lines of code written over 15 years by thousands of people. For greenfield work, a looser approach of prototyping and exploring often fits better. Dave pushes on the piece most teams drop: the feedback loop. Everyone agrees to review and validate, and then the next shiny feature shows up. They also cover what happens when an AI agent follows an over-detailed spec too literally, why systems thinking beats chasing every edge case, and how explore versus exploit plays out differently for a startup and a company with 10 million customers. This week’s takeaways: A structured, spec-driven SDLC pays off on large, complex systems where stability matters, but it can feel like far too much when you are just prototyping something new.Define enough up front to guide the work, then rely on regular check-ins and feedback loops to course-correct, because no spec can predict every case and an AI agent will happily take the shortcut you never meant to allow.Explore and exploit are not either/or. Organizations can now run both under one roof, as long as they know where they sit on the path from startup to established player and use judgment about how much structure to add.Listen to the full episode at definitelymaybeagile.com  Subscribe so you never miss an episode.  Have a question or topic you’d like us to cover? Reach out at [email protected]

AI agents will tell you everything works. Here is how to validate AI output when the mistakes are ones no human would ever make. Peter and Dave compare notes from building software, training material, and presentations with AI. The problems they keep running into are strange ones: the wrong database ID dropped into a system, 236 passing tests that test nothing, and five layers of abstraction added to a solution that needed none of them. Their answer borrows from good agile practice. Define what validation means before the agent starts, the same way a team agrees on its definition of done. Keep checking that the context you gave the AI is still relevant as the work moves. And keep someone in the loop who knows the problem well enough to look at the result and say, "Actually, you got this wrong." This week's takeaways: - Decide what "done" and "valid" mean before you hand work to an AI agent, and use a separate agent to grade what comes back. - A test suite that pings components or mocks everything out can report hundreds of passes and prove nothing, so ask for synthetic transactions that run through the whole system. - AI will happily over-engineer a small problem, so someone needs enough knowledge to ask whether the solution fits the size and scale of what you are actually trying to solve. Listen to the full episode at definitelymaybeagile.com Subscribe so you never miss an episode. Have a question or topic you'd like us to cover? Reach out at [email protected]

Giving AI agents names and a spot on the org chart makes people feel less accountable for the work, and it squeezes the agent into a role it doesn't need. Dave Sharrock and Peter Maddison dig into new research from the September/October 2026 issue of Harvard Business Review on what happens when organizations add named AI agents to the org chart. When people use AI as a tool, they own the result and check it carefully. When the same work comes from a personified agent, accountability quietly shifts to the software, and nobody is really holding it. Peter connects this to the idea of accountability sinks, the layers in an organization where responsibility disappears. They also talk about review fatigue, the growing pile of AI-generated documents, slides, and code that someone still has to read, understand, and sign off on. Onboarding an agent like a new hire still makes sense. Leaving it on the org chart with a name is where the trouble starts. This week's takeaways: - How people work alongside capable AI agents is still poorly understood, and the old problems of ownership, accountability, and decision making do not go away just because an agent is involved. - Review fatigue is real and getting worse, because cheap generation still means expensive human review for every artifact someone has to approve. - Naming an agent into a human role limits it to the shape of that role, while treating it as a tool in the workflow lets it work across boundaries in ways a person cannot. Listen to the full episode at definitelymaybeagile.com Subscribe so you never miss an episode. Have a question or topic you'd like us to cover? Reach out at [email protected]

AI speeds up building. It doesn't speed up deciding. The real bottleneck has moved to management, and organizations don't see it yet. In this episode, Peter and Dave talk with Bernie Maloney about why AI adoption is exposing a critical gap in organizational leadership. AI is accelerating delivery and implementation. But the pressure for deciding what's worth building has moved upstream faster than most companies can adapt. That means managers can't just be administrators anymore. They need to understand the work hands-on (the "player" part) while coaching teams to see the bigger strategic picture. Bernie walks through a three-dimensional view of Agile: output (how to build), outcome (how to solve problems), and impact (what problems are worth solving). Most organizations only operate in one. He also explains why the discovery plane—figuring out what to build in the first place—has to move closer to teams instead of staying locked at the management layer. That's where the real bottleneck lives now, not in engineering. This week's takeaways: Agile moved the bottleneck from production to deployment. AI is moving it again, this time to deciding what's worth building in the first place.Managers need to become player coaches: staying close to the actual work so they understand what's possible, while coaching people to think strategically about the system they operate in.Psychological safety and tolerance for intelligent failure have to come before speed. Without them, faster delivery just means faster mistakes.Listen to the full episode at definitelymaybeagile.com Subscribe so you never miss an episode. Have a question or topic you'd like us to cover? Reach out at [email protected]

Don't abandon Agile for AI. The real bottleneck isn't speed of delivery, it's organizational decision-making and clarity about value. Dave West, CEO of Scrum.org, warns that organizations adopting AI are making a critical mistake. They're abandoning foundational Agile practices, sprint planning, daily standups, retrospectives-  under the assumption that AI's speed removes the need for those ceremonies. But Dave's seen this pattern repeatedly: when organizations get faster delivery tools, the real bottlenecks become visible. And they're never about speed. They're about decision-making clarity, aligned incentives, and organizational structures that can't move that fast anyway. This conversation with Peter and Dave explores what's actually breaking in organizations that try to bolt AI onto broken systems. This week's takeaways: Don't throw out sprint ceremonies just because AI makes delivery faster. The intent behind planning, reviews, and retrospectives is still valid. Rethink how they work differently, not whether they're still needed.Understand the incentives driving individual behaviors, not just the organizational KPIs you set. Invisible incentives like status, power, and recognition often outweigh what's written on paper.When navigating organizational change around AI adoption, spend time understanding what actually motivates the people in the room. Ask simple questions and learn what's in it for them personally. Listen to the full episode at definitelymaybeagile.com Subscribe so you never miss an episode. Have a question or topic you'd like us to cover? Reach out at [email protected]

The Scrum Master role hasn't disappeared. It's been diluted, pushed outside the organization, or absorbed into everyone's job description. Peter Maddison and Dave Sharrock dig into what's actually happened to the Scrum Master and agile coach role as AI reshapes how teams work. They trace how a role that once had real impact got watered down as two-day certifications flooded the market, and why the deeper value was never the role itself but the culture of continuous improvement it was meant to build. Using Toyota's andon cord as a lens, they compare organizations that treat problems as learning opportunities against those just racing to get the line moving again. The stronger realization is understanding when continuous learning shifts from being a role-driven practice to a part of the culture. This week's takeaways: - The standalone Scrum Master role got diluted as it became widespread, and the certifications never guaranteed the facilitation and coaching skill the role actually required. - The real value was never the role, it was building a culture of continuous improvement, and that culture works best as a shared responsibility across a team rather than one person's job. - Toyota's andon cord shows the difference between organizations that treat a pulled cord as a signal to learn versus organizations that only care about getting the line moving again. Listen to the full episode at definitelymaybeagile.com Subscribe so you never miss an episode. Have a question or topic you'd like us to cover? Reach out at [email protected]

AI vendors are shifting from flat-fee pricing to consumption-based billing, and most organizations have no idea what their token spend is actually producing. Dave Sharrock and Peter Maddison break down what's driving the shift to AI token economics, why the old "$20 per user" budget model is breaking down, and why usage alone is the wrong thing to optimize for. They dig into the pattern showing up across organizations, where a small share of users account for half the token spend, and why chasing that number down misses the real question: what value did that spend create? The conversation covers KPI traps, model selection tradeoffs, and how to build the kind of honest, open culture that lets you actually govern AI spend without punishing your best people. This week's takeaways: - Token usage by itself is a bad KPI once your organization has moved past early AI adoption, because it stops measuring exploration and starts driving the wrong behavior. - The 10% of users driving 50% of the token spend aren't automatically the problem. Some are generating outsized value, and the only way to know is to ask them directly. - Managing AI cost well means pairing spend visibility and caps with an honest conversation about the value that spend is producing, not just sorting a table by usage. Listen to the full episode at definitelymaybeagile.com Subscribe so you never miss an episode. Have a question or topic you'd like us to cover? Reach out at [email protected]

Giving an AI agent real autonomy means accepting it will fail early and often before it gets good, the same curve organizations hit during any real change. Peter Maddison brings a stuck OAuth problem to the table: an AI agent that kept going in circles and couldn't find its way through. That leads into a conversation from Dave Sharrock's local AI meetup about an AlphaGo-style approach to AI agent autonomy: instead of specifying every step, you define hard constraints and let the model work out its own strategy inside them. Peter and Dave connect this to the Virginia Satir change curve, the same dip in performance that shows up when an organization tries a new way of working, and to the difference between using AI to optimize what you already do versus using it to rethink the business itself. They also get into how experiments like Andon Labs' AI-run cafes and vending machines use small dollar constraints to let a model learn from failure without real financial risk. This week's takeaways: - A well-articulated objective with clear guardrails lets an AI agent find its own path to a solution, even one you didn't expect or fully understand. - Real learning, whether it's an AI agent or an organization adopting a new way of working, comes with an unavoidable dip in performance that can't be planned away. - The bigger opportunity with AI isn't squeezing more efficiency out of an existing process, it's using AI to test entirely different ways a business could operate. Listen to the full episode at definitelymaybeagile.com Subscribe so you never miss an episode. Have a question or topic you'd like us to cover? Reach out at [email protected]

AI can write code faster than ever, but Peter Maddison and Dave Sharrock argue that coding was never the actual bottleneck in software delivery. In this conversation about AI software delivery, Peter and Dave dig into why faster coding hasn't solved the two problems that always mattered: knowing whether what you built is actually valuable, and knowing what to build in the first place. They connect this back to sprint length, arguing it was never set by how hard the coding is, but by how fast an organization can learn and decide. As AI generates more options and even makes decisions on our behalf, the conversation turns to what happens when judgment can't keep pace with output, and why product owners and stakeholders still need real time to validate high-risk calls. This week's takeaways: - Coding speed was never the real constraint. The two problems that still matter are knowing if something is valuable and knowing what to build in the first place. - Sprint length should be set by your organization's decision and learning latency, not by how fast code can be written. - As AI generates more options and even makes decisions for you, leaders need time and context to validate high-risk calls, because judgment doesn't speed up as easily as output does. Listen to the full episode at definitelymaybeagile.com Subscribe so you never miss an episode. Have a question or topic you'd like us to cover? Reach out at [email protected]

Organizational change resistance isn't dysfunction, it's a system doing exactly what it was built to do. Peter and Dave break down why structures, incentives, and leadership behavior create that resistance, and how AI is now exposing it faster than ever. Dave and Peter dig into what they call the organizational immune system: the structures, incentives, and habits that keep a company stable, and that fight back the moment you try to change them. They use the Boeing and McDonnell Douglas merger as a case study in how a shift in incentives can erode a culture built over decades, and how long it takes to rebuild that trust once it's gone. The conversation moves into how AI adoption doesn't fix broken systems, it amplifies the weak spots organizations have been avoiding for years, and forces conversations that used to be easy to put off. They close with a look at how value stream mapping can make an organization's hidden dependencies visible, so leaders can work with the immune system instead of fighting it. This week's takeaways: - Organizational structures exist to stabilize behavior, so treating them as barriers to simply remove often creates new problems you didn't expect. - Real change comes from adjusting incentives and giving people permission to experiment, not from stripping away the systems that hold the organization together. - AI adoption doesn't repair a broken process, it amplifies existing weak spots and forces the difficult conversations organizations have been putting off. Listen to the full episode at definitelymaybeagile.com  Subscribe so you never miss an episode.

Organizational honesty starts with information: can your team actually see what's happening, and can they say it without fear of pushback? Dave and Peter dig into why teams shade the truth when a deadline is on the line, and what actually creates room for honesty instead. They talk about the difference between activity data and real information, why cheap, near real-time visual management beats a hand-curated status report, and why the structure of a status meeting decides whether bad news gets absorbed or gets shot down. They also get into why understanding how work flows end to end matters more than staring at a single date on a calendar. This week's takeaways: Cheap, near real-time visual management pulled straight from your work management systems gives people something honest to talk about instead of a filtered report.Structure in status conversations matters because it lets people absorb bad news and adjust instead of reacting defensively, which makes it safer to bring problems forward next time.Understanding how work actually flows end to end, not just watching a deadline date, is what shows you where the real bottlenecks and constraints are.Listen to the full episode at definitelymaybeagile.com  Subscribe so you never miss an episode.  Have a question or topic you'd like us to cover? Reach out at [email protected]

AI is making it faster and cheaper to ship features. That doesn't mean you should ship more of them at once. Peter and Dave dig into a pattern they're both starting to see: organizations using AI-assisted development as a reason to bring back big upfront planning and large project releases. The logic makes a certain kind of sense. If AI can build faster, why not design bigger? But that reasoning skips the part that actually mattered when teams moved to product delivery in the first place: validating that you're building what customers actually need. The conversation covers why large releases make it harder to learn what's working, why feature parity with competitors is a trap, and what "North Star context" actually means when you're coordinating AI agents. The core argument: the planning layer is back in vogue for good reason, but the delivery layer still needs to be small and iterative. Cheaper to build doesn't reduce business risk. It just makes it easier to build the wrong thing faster. This week's takeaways: AI augmentation speeds up building and releasing features, but it doesn't replace the need to validate whether those features are what customers actually want.A big picture plan is useful as context for AI agents and delivery teams, but over-specifying every step upfront wastes time on details that will change anyway.The goal isn't projects vs. product delivery. It's combining a clear long-term direction with small, measurable, iterative delivery tied to real outcome metrics.Listen to the full episode at definitelymaybeagile.com  Subscribe so you never miss an episode.  Have a question or topic you'd like us to cover? Reach out at [email protected]

Tommy Cotter is Director of Data Products at Benzinga, a financial media company building the data infrastructure that sits behind trading platforms and investment apps used by millions of people daily. He's been navigating the shift to AI-assisted workflows in a space where speed and accuracy aren't just nice to have - getting it wrong has real consequences. In this episode, Peter and Dave talk with Tommy about what it actually looks like to build data products responsibly in a fast-moving AI environment. They get into where humans still need to be in the loop, how compliance has become a competitive signal, and why being nimble matters more than picking the perfect architecture from day one. Three things to take away from this conversation: Self-agency is real now. If you have a strong conviction about a product or problem, the barrier to building something has never been lower. That's a genuine shift from even five years ago.Security and compliance are no longer just internal concerns. In a world where AI startups spin up overnight, having invested in SOC2 or GDPR signals to customers that you're a legitimate, trustworthy operation. It's a market differentiator.Humans still belong in the system. Not everywhere, but in the right places. For low-risk, deterministic processes, let AI run. For anything client-facing or accuracy-critical, keep a human in the loop. Knowing the difference is the skill.If this conversation sparked something for you, send us your thoughts at [email protected]. And if you haven't already, hit subscribe so you don't miss the next one.

Royce Sin spent a decade at HSBC automating things nobody asked him to automate. He didn't ask for permission. He just did it, showed people the results, and let the time savings speak for itself. That instinct, to question why things are done a certain way and then actually do something about it, is what eventually led him into the AI space. In this episode, Peter and Dave sit down with Royce Sin to talk about what it actually takes for AI to stick inside an organization. Spoiler: it's not about the tools. We get into the tension between flexibility and reliability, why most people are being set up to fail with AI, and what it means to think like a manager when you're not one. Royce also shares his MIND framework, a practical way to think about AI adoption that he developed through hands-on work across enterprise and startup environments. There's also a good conversation about the trades, no-UI as an ideal, and why the most dangerous move in transformation is knocking down fences you don't fully understand. This week's takeaways: Think of AI as a new type of employee. Set it up for success the same way you'd set up your staff. Design roles and processes to match what it's actually good at.Not every rule is a hard rule. Before treating a constraint as a blocker, understand what's behind it. Some fences are load-bearing. Some aren't. Know the difference before you act.Don't just bring in AI. Know what outcome you're after. If you can't tell whether it's working, you don't have a tool problem, you have a clarity problem.Have a thought on any of this? Reach us at [email protected]