Conference season is back, and so are the real conversations. In this episode, Peter Maddison and Dave Sharrock catch up after a busy stretch of travel and dig into something Dave has been road-testing at conferences: why most people given access to AI tools freeze up, and what actually helps them move past that.

Dave ran a workshop at the Global Scrum Gathering in Vancouver for non-technical roles - product managers, Scrum Masters, agile coaches - people who've been told "use AI" but have no clear picture of where to start. What he found is that the problem isn't motivation or technical ability. It's the lack of scaffolding. Give people the right structure and the right room to experiment, and things shift pretty quickly.

The conversation then moves into multi-agent systems - how Dave's team built a group of agents that continuously refresh the workshop itself based on current thinking. Peter adds his own take on testing these systems with personas and automated quality evaluation. It gets a bit technical, but in the best way.

This is a good episode if you're thinking about how to help your organization actually use AI, not just adopt it on paper.

Key Takeaways:

• Context beats generic. Prompts work when they're specific to your role and your actual problems. A product manager needs product management context, not a one-size-fits-all example.
• Think in teams, not steps. Multi-agent systems work best when you treat them like a team reviewing an artifact, each agent checking for something different, rather than a linear build process.
• Don't assume everyone gets it. The gap between people who use AI daily and people who tried it once and gave up is wider than most of us realize. Getting both groups in the same room is where the real learning happens, for everyone.

Have a question or something to add? Reach out at feedback@definitelymaybeagile.com or find us at definitelymaybeagile.com. And if you're finding the show useful, subscribing and leaving a review goes a long way.

Most organizations think they're doing AI. They've bought the licenses, rolled out the tools, and told the team to start using Copilot. But adding AI on top of a 40-year-old process isn't transformation. It's decoration.

Andre Kaminski, Director of Advanced Technology Solutions at WorkSafeBC and author of "The AI-Native Software Development Lifecycle," joins Peter and Dave to talk about what it actually means to rebuild your delivery process around AI, not just bolt it on.

They get into why optimizing code generation alone is the wrong focus, what the six phases of an AI-native SDLC look like in practice, and why the biggest challenge isn't the technology at all. It's the identity shift that comes with it.
If your organization is asking "which AI tool should we use?" this episode will help you realize that's probably the wrong question.

In this episode:

• Why AI-augmented and AI-native are very different things
• The compounding learning effect and why early adopters are pulling further ahead every month
• What prompt architecture actually means and why it matters more than code
• How to think about governance when prompts become your new source of truth

Want to keep the conversation going? Drop us a line at feedback@definitelymaybeagile.com or find us at definitelymaybeagile.com. If this episode got you thinking, share it with someone who needs to hear it.

Agreeing on an idea doesn't mean you both understood the same thing. Dave Sharrock and Peter Maddison dig into why shared context breaks down in practice, and how AI makes that problem harder to ignore.

This week's takeaways:

• Intent is always imperfect. Define how you'll validate it, not just what it is.
• Ambiguity in context isn't a bug. It's necessary. Validation is how you confirm you're aligned.
• Drive down the cost of validation, not just the cost of building.

If this landed, share it with someone navigating the same tension. And reach out at feedback@definitelymaybeagile.com - we read everything.

It doesn't happen all at once. A great idea comes out of a strategy session. Someone turns it into a PowerPoint. Another person summarizes that PowerPoint with AI. By the time it reaches the team building it, the sharp edges are gone and nobody quite remembers what made the idea worth pursuing in the first place.

Peter and Dave dig into a problem that's older than AI but getting harder to ignore. How does intent get lost as it travels through layers of people, tools, and artifacts? What does a shared context document do that a business case can't? And what can the architectural world teach the product world about keeping the thread from unraveling?

Key takeaways:

• Moving artifacts backwards and forwards through an organization strips out nuance at every step. A single central context document is a more honest way to carry intent from strategy to delivery.
• AI is being actively encouraged in most organizations right now, and in using it, teams may be quietly eroding the ideas behind what they're building without realizing it.
• If your outcomes don't match your original intent, the handoff chain is usually where things went wrong. That's worth looking at before blaming the team.

Try this: Trace one idea from your last strategy session all the way to what actually got built. See if you can find where it changed. Then come tell us what you found at feedback@definitelymaybeagile.com.

Most organizations think they have a capacity problem. They usually don't.

What they have is a work-in-progress problem. And those two things call for very different solutions.

In this episode, Peter Maddison and Dave Sharrock dig into one of the most persistent headaches in organizational management: capacity tracking. Why does the instinct to measure utilization backfire? Why does loading people up to 100% actually slow things down? And what should leaders be asking instead?

The conversation covers the real cost of context switching, why that "nearly done" project is probably further away than it looks, and how AI is making all of this more urgent, not easier.

Three things to take away from this episode:

1. 100% utilization is not a goal. It's a warning sign.
2. The right question isn't "how much capacity do we have?" It's "how much work in progress can we actually sustain?
3. AI accelerates your breaking points.

If this conversation resonated, there's more where it came from. Peter Maddison and Dave Sharrock explore these kinds of organizational challenges every week on Definitely Maybe Agile - the podcast that gets into the real complexity of modern ways of working, without the buzzwords.

Listen wherever you get your podcasts, or visit definitelymaybeagile.com to catch up on past episodes and reach out with your own questions.

AI is changing how products get built. That part isn't news. But it's also changing who needs to do what - and that's a conversation most organizations haven't had yet.

In this episode, Peter and Dave dig into one of the more interesting tensions emerging in 2026: as coding agents take on more of the actual development work, the thing that drives quality output isn't just better tooling. It's better context. Clear, structured, well-owned context that tells agents what you're actually trying to build, who it's for, and what can't be compromised.

Which raises a real question. Who owns that? Where does it live? And what happens when it's missing - which, let's be honest, it usually is?

They get into the rise of "context engineering" as a role, why the name creates its own problems, and what this shift means for product owners, product managers, and the long-standing gap between business and technology teams.

Key takeaways from this episode:

• Most organizations have never truly written down their product intent in a structured, usable way. AI is making that gap impossible to ignore.
• Good context drives better outcomes from agents - and the work of capturing, structuring, and maintaining that context needs a clear owner.
• Start asking: what context exists to guide your products? Where is it stored? Who creates it? Who picks it up and moves it through the system?
• The business and technology divide matters more now, not less. You can't afford to throw things over the wall anymore. The two groups need to work closely together, not in parallel.
• What's new here isn't the idea. It's the urgency. These are transformations organizations have been attempting for years. AI is just forcing the issue.

Want to continue the conversation?

If this episode brought up questions about how your teams are navigating the shift to agentic development - or where context ownership actually sits in your organization - reach out at feedback@definitelymaybeagile.com. We'd love to hear what you're seeing.

A lot of organizations are betting that AI will make their teams faster. Some of them are right. Most are solving the wrong problem.

AJ Bubb, founder of MxP Studio and host of Facing Disruption, joins Peter and Dave to talk about what actually happens when AI lands in a development team without fixing the system around it. If engineers can't get approvals, can't get access, and spend half their day in meetings, AI just means they produce more output the organization still can't handle. That's not a tooling problem. It's a structural one.

They also get into velocity without direction, what ownership really looks like when a ticket gets blocked, and why synthetic user testing might be the most polite way to avoid talking to actual customers.

This Week's Takeaways

• Own the problem from the customer all the way down. When something is blocked, it's still yours until it moves.
• When an outcome surprises you in either direction, ask whether your model was wrong. Most teams take the win and move on. The ones that improve don't.
• Before reaching for a technical solution, ask why five times. The problem someone walks in with is usually the invitation to a conversation, not the actual problem.

If this episode got you thinking, we'd love to hear from you. Drop us a note at feedback@definitelymaybeagile.com or leave a review on your podcast app. And if you know someone navigating AI adoption right now, send this one their way.

Most organizations are running some version of a project operating model or a product operating model - or, more honestly, an uncomfortable mix of both. In this episode, Peter Maddison and Dave Sharrock get into what actually separates these two approaches, where the tensions show up, and why copying what works somewhere else rarely lands the way you expect.

They dig into how the nature of your work - ordered versus unordered, stable versus volatile - should shape how you plan, who holds decision rights, and how closely your experts need to stay involved. They also talk honestly about the hybrid trap: why trying to be all things to all teams usually ends up serving nobody, and what a smarter version of "borrowing from both" can actually look like.

Real examples from large organizations, including a couple of banks, show just how messy it gets when the model is mandated from the top without enough room for context.

Key takeaways from this episode:

• There is no universal operating model. The right fit depends on your context right now, not what worked somewhere else.
• If your plan is constantly changing, lean toward the product side. If it's stable and predictable, the project side probably serves you better.
• Be intentional about your choices. Ask why you're organizing work the way you are, and how you'll know if it's working.
• Getting an outside perspective matters. It's easy to stay stuck in familiar patterns without someone who can see the system clearly and name what isn't working.
• Get your operating model working before you add AI into the mix. Throwing new tools at a system that isn't working yet just breaks things faster.

Which end of the spectrum does your organization sit on right now - and is it actually working for you? Leave a comment below. We read everything.