Podcast appearances and mentions of Mike Cohn

Scrum Needs Leadership Support - Mike CohnOne of the biggest mistakes leaders make is treating Scrum or agile as something isolated to the teams.The teams will be agile.The teams will do Scrum.The teams will hold the meetings.The teams will become faster.But the surrounding organization remains largely unchanged.That is not sustainable.Scrum asks teams to focus, collaborate, inspect, adapt, and deliver valuable increments of work. For that to happen, leaders have to create an environment where those behaviors are possible.That often means eliminating silos and forming cross-functional teams. It means giving teams a challenge and then getting out of the way enough for them to solve it. It means resisting the temptation to second-guess team decisions. It means allowing teams to tell the truth about overly optimistic deadlines, unrealistic scope, and risks they see in the work.A team cannot do its best work while being pressured to commit to things it does not believe are feasible.A team cannot be self-managing if every meaningful decision is made somewhere else.A team cannot deliver predictably if leaders constantly redirect it and then act surprised when the original plan is not met.Good leadership support means shaping the environment so teams can succeed.When a desired deadline or desired scope is not feasible, leaders and teams should treat that as a shared problem to solve.Maybe the scope can be reduced. Maybe more time is needed. Maybe a different approach is possible. Maybe another initiative should be delayed. Maybe the organization needs to accept more risk.The first step is telling the truth.Scrum works better in organizations where truth is welcome.Try this: The next time a team says a deadline or scope is not feasible, don't ask, “How can you still make it?” Ask, “What would need to change for this to become feasible?”That question turns the conversation from pressure into problem solving.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Focus Requires Saying Not Yet ~ Mike CohnMany Scrum problems are really focus problems.Organizations try to do too many things at once. They have too many initiatives, too many urgent requests, too many stakeholders, too many priorities, and too little willingness to say “not yet.”Scrum makes this visible.A sprint creates a short planning horizon for deciding what the team can accomplish next. A sprint goal identifies the outcome that matters enough for the team to organize around it. A product backlog makes visible what is more important than what.Those are uncomfortable conversations in an organization that wants everything at once.So the difficulty often gets pushed onto teams and product owners.Product owners are asked to satisfy too many stakeholders. Teams are asked to start more work than they can finish. Leaders ask for predictability while priorities continue to change. Everyone wants the benefits of focus without making the tradeoffs focus requires.That does not work.A product owner can help by bringing focus to the team. That means saying what should be done and, just as importantly, what should not be done right now.But product owners need support.A product owner surrounded by stakeholders who believe every request is urgent will struggle to create focus unless leaders help establish the expectation that not everything can be first.This is one reason Scrum can feel frustrating.The team is asked to commit to a sprint goal, but the organization keeps behaving as if everything is urgent. The team is asked to be predictable, but priorities keep changing. The product owner is expected to make good priority decisions, but every stakeholder wants a different answer.Scrum exposes the need for difficult prioritization.That exposure is useful. It gives the organization a chance to make better decisions.Try this: Before the next sprint, ask stakeholders and leaders to complete this sentence:For this team to succeed in the next sprint, we are choosing not to work on ____ yet.If no one can fill in the blank, the team probably does not have focus. It has a list of competing demands.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Velocity feels like proof.  Fifty story points done, a bigger number than last sprint, a box checked.  But velocity measures how busy a team is, not whether anything valuable reached the customer.  Kate Megaw and Ryan Smith take apart the metric everyone loves to report and rebuild the case for measuring what matters.  Velocity, they argue, was never a metric at all. It is an internal planning tool, Mike Cohn's “yesterday's weather”, useful for forecasting and useless for judging.  From there the conversation turns to the measures that actually signal agility: outcome over output, flow metrics like lead time, work in progress limits, emergent work per sprint, flow efficiency, and the strategic questions executives really care about, such as whether the business moved forward.  Along the way Ryan shares the MVP that 300 people found on their own, and Kate lands the question that cuts through it all: if your velocity doubled tomorrow, would your customers even notice? Velocity is vanity.  Outcomes are reality.  Agility lives in the flow.

What Cinco de Mayo Can Teach Us About Agile - Mike CohnToday seems like a good day to celebrate Cinco de Agile.Cinco de Mayo commemorates the Battle of Puebla, when a smaller, less-equipped Mexican force defeated a larger French army.There's an agile lesson in that.The side with the bigger plan, more resources, and more confidence doesn't always win.Sometimes the winner is the side that can adapt faster.That's one of the biggest differences between agile and waterfall.Waterfall assumes that if we plan thoroughly enough up front, we can control the outcome.Agile assumes that once real work begins, we'll learn things we couldn't have known at the start.When customers change their minds, markets shift, or the team learns something new, fast feedback beats slow certainty.A team that delivers something small, gets feedback, and adjusts can outperform a team that spends months moving confidently in the wrong direction.That's the real lesson.It's not that small always beats big.It's not even that agile always beats waterfall.It's this:In changing conditions, adaptability is your biggest competitive advantage.So if your current plan feels a little too certain, it may be worth asking one uncomfortable question:What are we doing to learn faster?Because in product development, learning speed often determines who wins.Happy Cinco de Agile.How to connect with AgileDad:- [website] ⁠⁠⁠https://www.agiledad.com/⁠⁠⁠- [instagram] ⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠- [facebook] ⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠- [Linkedin] ⁠⁠⁠https://www.linkedin.com/in/leehenson/

A Plan is Not a Commitment - Mike CohnOne of the fastest ways leaders create overcommitment is by treating a plan like a guarantee.An agile team builds its plan from what it knows at the time: assumptions, estimates, priorities, and constraints. That means every plan is probabilistic. It has some chance of coming true, but that chance is not 100%.That is why I coach teams to aim for about 80% success.Aim much higher than that, and teams will often bring too little into the plan. Aim much lower, and others in the organization do not get the predictability they need to make their own plans.So yes, it is fine to ask a team for a commitment. But the team determines what they can commit to.And leaders need to understand what that requires.A team asked for a commitment will include a margin of safety between its plan and its commitment. It has to. A commitment has to survive interruptions, surprises, dependencies, and the normal friction that shows up once work begins.That means a commitment needs margin.And margin is the part leaders often resist.A team may plan to complete forty points of work. That does not mean they should commit to forty.If they commit to all forty, they are assuming very little will go wrong.That is not a real commitment. It is simply hoping the plan goes perfectly.Real commitment is what the team can stand behind, even when the sprint is not perfect.So if you want an honest commitment, do not ask the team to commit without changing anything else.Ask instead: What could you commit to with confidence?What margin do you need?What would have to be true for this to be a real commitment instead of a hopeful plan?Those questions force the real tradeoff into the open.If the date is fixed, scope may need to flex.If the scope is fixed, time may need to flex.But something usually has to move.That is the part leaders often skip. They hear a plan, silently upgrade it to a commitment, and then act surprised when the team misses it.Do not do that.A plan is useful. A commitment is valuable. But they are not interchangeable.How to connect with AgileDad:- [website] ⁠⁠⁠https://www.agiledad.com/⁠⁠⁠- [instagram] ⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠- [facebook] ⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠- [Linkedin] ⁠⁠⁠https://www.linkedin.com/in/leehenson/

A lot of organizations say they've “gone Agile,” but still struggle with missed deadlines, unclear priorities, and teams that feel busy without delivering better outcomes. In this episode, Scott Dunn joins Brian Milner to unpack why Agile ROI is so often misunderstood and what leaders should actually be measuring instead.    Overview What does a successful Agile transformation actually look like? Too often, organizations adopt Scrum or Agile practices because everyone else is doing it, without first defining the business outcomes they hope to achieve. The result is predictable: teams follow the motions of Agile while leadership struggles to see measurable value. In this conversation, Brian Milner and Scott Dunn explore why ROI conversations around Agile frequently go off track and how leaders can reconnect Agile practices to meaningful business goals like faster delivery, improved customer satisfaction, stronger collaboration, and better adaptability. They discuss the hidden cost of operationalizing Agile too early, why coaching and leadership alignment still matter, and how the rise of AI makes strong Agile fundamentals more important, not less.   References and resources mentioned in the show: Scott Dunn #104: Mastering Product Ownership with Mike Cohn #132: Can Nice Guys Finish First? with Scott Dunn Do the Proven Benefits of Agile Training Justify the Costs? by Mike Cohn Subscribe to the Agile Mentors Podcast   Want to get involved? This show is designed for you, and we'd love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum.

When The Work Wont Fit, Make It a Shared Problem - Mike CohnWhen a team says, “We can't do all of that by then,” many leaders make the same mistake: They push harder.They restate the deadline. They repeat the importance. They ask for more effort, more creativity, or more commitment.But once the team has told you the work will not fit, pressure is usually the wrong next move.Your job at that point is not to force a better answer.Your job is to help find a better solution.That starts by treating the gap as a *shared* problem.Instead of asking, “Why can't you do it?” ask: What is making this too big?What part is driving the complexity?What would a good-enough version look like?What could we defer and still get the outcome we need?Those questions change the conversation.Now the team is not defending an estimate. They are helping solve the business problem.And that is where leaders add the most value.Sometimes the issue is scope. Sometimes it's a dependency. Sometimes, one edge case is making everything larger than it needs to be.Until you understand that, pushing for the original ask usually just creates a worse plan.A smaller, smarter solution delivered on time is often far better than a bigger promise the team cannot actually keep.So when the work will not fit, do not treat that as resistance.Treat it as information.The team is showing you where the real problem is.Your role is to help decide what matters most, what can move, and what version solves the problem well enough for now.Because planning works better when the request belongs to the leader, but the problem belongs to everyone.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Let's play a quick round of Two Truths and a Lie.Here are three statements about agile. Two are true. One is false.Read them over and see if you can spot the lie before I reveal it. Agile teams should be willing to change their plan for the sprint if they discover a better way to meet the sprint goal.Estimation in agile is most useful for helping teams forecast and make trade-offs, not for holding individuals accountable.A team that consistently finishes every planned story in every sprint is demonstrating a healthy, predictable agile process.The lie is #3.That statement sounds responsible, disciplined, and maybe even a little impressive. Which is exactly why it fools people.It reflects a common misunderstanding of agile: the idea that a good team is one that is always comfortable, always certain, and always exactly on plan.But healthy agile teams are not defined by perfect adherence to a prediction. They are defined by how well they pursue outcomes, adapt to what they learn, and make sensible decisions in the presence of uncertainty.Let's look at each statement.A sprint plan should guide the team, but it should not trap the team. At the start of a sprint, the team creates the best plan it can with the information available at that moment.Once the sprint begins, though, the team learns more. A technical approach that seemed promising turns out to be awkward. A dependency proves easier than expected. A simpler solution emerges. Or a conversation reveals a better way to achieve the intended outcome.When that happens, a good agile team should be willing to adjust. The important thing to preserve is the sprint goal rather than every detail of the original plan.The goal provides focus. The selected stories, tasks, and implementation approach are simply the team's current best thinking about how to reach that goal. If the team discovers a better path, it should take it.Changing the plan during a sprint is not a sign of weak discipline. In many cases, it is evidence that the team is paying attention and responding intelligently to what it learns.Teams get into trouble when they stick to the initial plan even after new information shows a better way forward. Agile works best when teams stay committed to the goal while remaining flexible about how to achieve it.Estimation is most helpful when it supports planning and decision-making. Teams estimate so they can answer practical questions like these: How much work can we likely take on?When might a larger effort be completed?If we add this item, what will need to move?Are we taking on too much uncertainty at once?Those are valuable questions, and estimation can help teams answer them.Where estimation becomes far less useful is when it is turned into a tool for judging individual performance.Once estimates are used to hold individuals accountable, people naturally become more defensive with them. Estimates get padded. Uncertainty gets hidden. Conversations become less honest. The numbers may still exist, but they stop helping the team make good decisions.That is why I prefer to keep estimation focused on decision-making. Estimates do not need to be exact to be useful. They only need to be good enough to help a team forecast, weigh options, and recognize when it may be taking on too much. A team that finishes every planned story in every sprint may look predictable. But if that happens all the time, I would not automatically consider it a sign of health. In fact, I would probably wonder whether the team is planning too conservatively.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Why Pressure Backfires Faster Than Leaders Think - Mike CohnIf your team keeps overcommitting, the answer is probably not more pressure.It may be less.Most teams do not need help being optimistic. They already want to believe they can get more done. They want to be helpful. They want to be seen as capable. They want to say yes.So when a leader adds pressure, even subtly, it rarely creates a better plan.It creates a less honest one.And pressure is not always loud. Sometimes it sounds like urgency. Sometimes it sounds like enthusiasm. Sometimes it sounds like, “This would really help us hit our goals this quarter.”But teams hear the message underneath the message: We really want this to fit.Once they hear that, many teams do what people do under pressure. They lean toward the optimistic case. They discount risk. They stop saying the uncomfortable part out loud.That does not make the work smaller. It just makes the plan weaker.Your job during planning is not to squeeze confidence out of the team. Your job is to create the conditions for truth. That means asking questions like: What assumptions are we making?What could derail this?What feels least certain right now?What would have to go unusually well for this to work?Those questions do not slow planning down. They improve it.Because pressure does not eliminate uncertainty. It drives uncertainty underground. And once that happens, overcommitment is usually just a matter of time.If you want more realistic commitments, do not start by pushing harder.Start by making it safer to tell the truth.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Many agile struggles don't start with the team. They start with leadership decisions that seem reasonable but create friction, confusion, or misalignment over time. In this episode, Mike Cohn outlines the patterns that most often hold organizations back and what leaders can do differently.   Overview In this episode, Brian Milner and Mike Cohn examine the leadership decisions that most often derail agile efforts. Rather than focusing on team-level practices, the conversation centers on how leadership behavior shapes outcomes across the organization. Mike highlights several recurring issues: treating agile as a process change instead of a mindset shift, scaling before understanding what works, limiting product owner authority, and prioritizing speed over focus. He also addresses how well-intentioned leadership actions can unintentionally slow teams down or create dependency. The discussion emphasizes that agile is not something leaders delegate. It requires changes in how leaders make decisions, set boundaries, and engage with teams. When those changes do not happen, teams may follow the motions of agile without seeing meaningful improvement. If your organization is “doing agile” but not seeing the expected results, this episode offers a practical way to assess where leadership decisions may be contributing to the problem—and where to adjust first.   References and resources mentioned in the show: Mike Cohn #118: The Secrets to Agile Success with Mike Cohn #143: What Still Makes Teams Work (and Win) with Jim York Why Teams Matter More Than Ever for Innovation by Mike Cohn How To Fail With Agile: Twenty Tips to Help You Avoid Success by Mike Cohn + Clinton Keith Subscribe to the Agile Mentors Podcast    Want to get involved? This show is designed for you, and we'd love your input.   Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.   Got an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.  Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Why Estimating and Planning Still Matter - Mike CohnOver the years, I've talked with a lot of teams who've been burned by estimating and planning.They've seen estimates treated as promises.Plans turned into contracts.Teams punished for being wrong rather than rewarded for learning.Given experiences like those, it's understandable that many teams conclude the solution is to eliminate estimating and planning altogether.I think that's a mistake.Estimating and planning still matter—not because the future is predictable, but because it isn't. Teams and organizations still have to make decisions about what to work on, what to delay, and what risks they're willing to accept. Those decisions don't disappear just because we stop estimating.Any time we choose one piece of work over another, we're estimating. The real choice isn't whether to estimate, but whether those estimates are explicit or implicit. In my experience, explicit estimates create transparency. Implicit estimates just hide the guessing.One of the biggest problems with estimating is the belief that estimates exist to be accurate. A better question is whether an estimate is good enough to support the decision being made. When teams make that shift, estimating becomes far less stressful—and far more useful.The same is true of planning. Planning doesn't reduce adaptability. Over-commitment does. Good planning aligns assumptions and intent so teams can adjust quickly when things change.I often hear people say, “Estimates are always wrong.” Being wrong isn't the real problem. Estimates are hypotheses, and reality supplies the data. The real failure is treating estimates as promises and punishing teams when reality turns out to be more complex than expected.Before estimating or planning, I encourage teams to pause and ask three questions: What decision does this support?What happens if we're wrong?Who will use this information—and how?If those questions don't have clear answers, the problem usually isn't how the team is estimating.It's why.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Not Every Backlog Item Needs Detail - Mike CohnHere's something I've noticed over the years:Many teams think backlog refinement means making the entire product backlog detailed and “ready.”That's not how a healthy backlog works.A well-managed product backlog should have a gradient of clarity.Items near the top of the backlog—the ones you're likely to work on soon—should be clear and reasonably detailed. They should have acceptance criteria, clarified assumptions, and enough shared understanding that the team can confidently bring them into a sprint.But items further down the backlog should be less detailed.They might be nothing more than a sentence or two.It's not wrong to leave lower backlog items vague. It's the right and agile thing to do.For example, imagine you're building a travel booking website. Early on, you might have detailed backlog items about booking airfare and booking hotels. Those are core features, so they deserve detail.But you might also have an item about booking cabins on a cruise ship. If cruises aren't central to your product, that item can stay vague for a long time. It doesn't need to be “Sprint Planning ready” six months before anyone will work on it.If you fully refine backlog items far in advance, you're doing a lot of work on items that will change, move, or disappear.So rather than trying to keep the whole backlog “ready,” focus your refinement effort where it matters most:At the top.Refinement should make sprint planning easier.That happens when the next sprint or two is well understood—not when the product backlog is documented 50 items deep.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Which Leadership Pattern Shows Up Under Pressure? - Mike CohnEvery year around April 1st, we like to have a little fun.But as with most good humor, there's usually a grain of truth underneath it.After working with thousands of teams and leaders over the years, one thing has become very clear: agile rarely succeeds or fails because of a framework. It succeeds or fails because of leadership behavior under pressure.When deadlines tighten…. When scope grows…. When velocity dips…. When stakeholders ask uncomfortable questions…Patterns emerge.Some leaders protect the outcome.Some protect the date.Some protect the process.Some protect momentum.None of these are “good” or “bad.” They're instincts. And under enough pressure, we all fall back on instinct.So this year's April Fools exercise is a simple (and only slightly unscientific) question:Which leadership archetype shows up most often?Answer it about yourself. Or answer it about someone you work with.Just choose the responses that feel uncomfortably familiar.The results are 100% accurate. Approximately.It's easy to laugh at archetypes.It's harder to recognize that under pressure, most of us drift toward one.Agile frameworks don't fail because teams forget a ceremony. They struggle when leadership instincts unintentionally override the conditions that make empiricism work: transparency, adaptation, and trust.The good news? Leadership patterns aren't fixed traits. They're habits. And habits can change.If this exercise felt a little too accurate, that's not a problem. It's an opportunity.Because small shifts in how leaders respond — to scope, to deadlines, to uncertainty — can have an outsized impact on how teams perform.That's the part that isn't a joke.If you're curious what those shifts look like in practice, we've spent the last two decades helping leaders explore exactly that.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

The Most Underrated Advantage of Short Sprints - Mike CohnA recent Gallup survey found that 80% of employees who received meaningful feedback in the past week are engaged at work.For comparison, Gallup's overall engagement numbers are often around 30%.That's a striking gap.It suggests something many leaders overlook: performance may depend less on changing team structure and more on improving feedback inside the structure you already have.When results lag, organizations often reach for the org chart. They reorganize teams, redraw reporting lines, or debate how many teams a coach or Scrum Master should work with.Sometimes those changes help. But they rarely go far if feedback is infrequent, unclear, or missing altogether.Feedback isn't just a management technique. It's a strategic advantage.And agile teams have been building that advantage into the way they work for years. When people talk about one- or two-week sprints, they usually focus on speed. “We need to move faster.”“We need more output.”“We need shorter release cycles.”But speed isn't the real advantage of short sprints.The advantage is shortening the time between action and learning.A sprint isn't a delivery cycle. It's a feedback cycle.Each sprint gives a team a natural point to stop and ask: Did we build the right thing?Did we misunderstand the need?Are we still aligned with stakeholders?Are we learning what we hoped to learn?The shorter the sprint, the shorter the gap between assumption and validation.That's not about velocity. That's about reducing risk. Early Scrum teams often worked like this:Sprint, sprint, sprint… then release.That pattern made sense at the time in the 1990s and early 2000s. It was a huge improvement over what had come before. But it meant some feedback arrived in a big, delayed batch after the release.Over time, many teams evolved to:Sprint, release, sprint, release.And today, many modern teams have gone further still. They release whenever it makes sense—sometimes multiple times per sprint, sometimes many times per day.In other words, modern agile teams have largely decoupled sprints from releases.So if sprints aren't primarily about shipping anymore, what are they for?Sprints provide a reliable cadence for feedback and alignment—even when delivery happens continuously. Many organizations treat the Sprint Review as a demo.It's not.It's where reality gets a vote.The Sprint Review is where the team inspects what was built with the people who care about it, and adjusts course based on what they learn.When that meeting becomes optional, rushed, or performative, you don't just lose a ceremony. You lose your learning loop. And you start optimizing for finishing work instead of finishing the right work.If weekly feedback really is one of the biggest drivers of engagement and performance—as Gallup's numbers suggest—then the Sprint Review isn't overhead. It's how you reduce rework, prevent expensive surprises, and stay aligned with what actually matters. Of course, simply running one-week sprints doesn't guarantee meaningful feedback.Stakeholders can skip reviews.Teams can ignore input.The conversation can stay superficial.Short cycles create the opportunity for feedback. Leaders decide whether to use it.That's where the advantage lives.If you're running one- or two-week sprints, ask yourself:Are we using sprints as delivery deadlines—or as learning deadlines?Because the real power of agile isn't producing more every two weeks.It's learning more every two weeks.And that's a competitive advantage that will help you succeed with agileHow to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Most teams say they want to improve. Few actually build the habits that make it happen. In this episode, Brian and Lance break down what separates teams that learn from teams that stall—and what leaders do that quietly gets in the way.   Overview What does it really take to become a learning team? In this episode, Brian Milner and Lance Dacy walk through five habits that show up in teams that continuously improve—and the leadership behaviors that either support or shut them down. From psychological safety and truth-telling to short learning cycles and focusing on the right problems, they unpack what actually drives improvement inside real organizations. Along the way, they challenge common assumptions about silence, metrics, and “heroic” problem-solving, and offer practical ways leaders can shift their approach starting immediately. If your team feels stuck, busy but not improving, or hesitant to speak up, this conversation gets to the root of why—and what to do about it.   References and resources mentioned in the show:   Lance Dacy Blog: Why Teams Matter More Than Ever for Innovation by Mike Cohn #143: What Still Makes Teams Work (and Win) with Jim York #171: Why Agile Teams Succeed—or Don't with Colin Fisher Subscribe to the Agile Mentors Podcast    Want to get involved? This show is designed for you, and we'd love your input.   Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.  Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Is Sprint Planning Quietly Hurting Teamwork? - Mike CohnI hated group projects when I was in school. I didn't want to rely on others for success. I wanted to be accountable for what I'd personally done.Teams that are new to agile often feel the same way.A developer will gladly take responsibility for their own code. But tell that same developer they're also responsible for someone else's code and you'll often get a confused look.And yet shared team accountability is one of the biggest predictors of whether an agile transition succeeds. High-performing agile teams understand: we succeed or fail together.Until that shared accountability exists, people experience their “commitment” as individual. I have my tasks, you have yours. That mindset leads to predictable behaviors: People stick to the parts of the product they already know.They avoid work outside their primary skill or role.They optimize for being “done with my work,” not for finishing as a team.So how do you help a team move from personal accountability to team accountability? Team accountability doesn't exist without personal accountability. If someone doesn't feel responsible for completing work that is clearly theirs, they won't feel responsible for the work of others.A practical place to reinforce this is the Daily Scrum. Listen for whether people clearly state what they finished since yesterday—and whether they did what they said they would. If not, help the team talk about why, and what they'll change today. Sprint Planning is your next best lever. Near the end of planning, ask a simple question:“Can we, as a team, meet the Sprint Goal and deliver these items?”Emphasize that the sprint backlog represents a team commitment. If one person is overloaded, we don't wish them good luck, we offer to help.That means  team members should speak up when someone is taking on too much, and then discuss how to lighten the load—by shifting work, pairing, swarming, or reducing scope.Team accountability will always be bounded by skills. A programmer won't suddenly do award-winning design work. But they might research image options, draft alt text, or assemble reference examples—small contributions that protect the bottleneck and help the team finish together.One of the most practical ways to build shared accountability is to broaden skills across the team.Look for opportunities for pairing, mobbing, or short “teach me” sessions where teammates transfer knowledge as they work. Then protect time for it. People will (rightfully) resent being told to broaden skills if they're expected to do it on nights and weekends. If you want team accountability, stop allocating tasks during sprint planning.Instead of pre-assigning everything, leave tasks unassigned and have team members pull work from the sprint backlog day by day. This keeps work flowing, increases collaboration, and makes it easier for people to help where help is needed.Personal accountability matters. But to succeed with agile, teams have to move beyond “my tasks” and toward “our outcome.”How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

AI Is Changing The Economics of Software Development - Mike Cohn

Many product teams are busy, but not necessarily effective. Brian Milner talks with product consultant Jason Knight about why so many organizations struggle with prioritization, customer insight, and measuring success—and what it takes to build a product organization that actually delivers value.   Overview What does it really mean to transform a product organization? Brian Milner sits down with product consultant and One Knight in Product host Jason Knight to explore the gap between how product management is described in books and how it actually works inside most companies. They discuss the reality many teams face: massive backlogs full of competing priorities, pressure from stakeholders, and organizations that say they are customer-focused but rarely talk to customers. Jason shares practical perspectives on prioritization, strategy, and why good product teams must learn to say no—even to good ideas. The conversation also dives into customer discovery, the barriers that keep teams from speaking directly with users, and how organizations should think about measuring success beyond simply “building the feature.” If your organization is trying to move beyond feature factories and build a stronger product practice, this episode offers a grounded look at where to start.   References and resources mentioned in the show: Jason Knight One Knight in Product Podcast Blog: What Does a Product Owner Do, When, and Why? Blog: How to Ensure You're Working on the Most Important Items Each Iteration by Mike Cohn #124: How to Avoid Common Product Team Pitfalls with David Pereira #154: The Underpowered PO with Barnaby Golden Subscribe to the Agile Mentors Podcast    Want to get involved? This show is designed for you, and we'd love your input.   Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.   Got an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.  Jason Knight is a product consultant, coach, and host of the One Knight in Product podcast who helps scaling B2B companies move beyond feature factories and build product teams that deliver real business impact. He works with organizations to connect strategy to execution through fractional product leadership, workshops, and coaching that bring clarity, alignment, and measurable results.  

The Most Underrated Advantage of Short Sprints - Mike CohnA recent Gallup survey found that 80% of employees who received meaningful feedback in the past week are engaged at work.For comparison, Gallup's overall engagement numbers are often around 30%.That's a striking gap.It suggests something many leaders overlook: performance may depend less on changing team structure and more on improving feedback inside the structure you already have.When results lag, organizations often reach for the org chart. They reorganize teams, redraw reporting lines, or debate how many teams a coach or Scrum Master should work with.Sometimes those changes help. But they rarely go far if feedback is infrequent, unclear, or missing altogether.Feedback isn't just a management technique. It's a strategic advantage.And agile teams have been building that advantage into the way they work for years. When people talk about one- or two-week sprints, they usually focus on speed. “We need to move faster.”“We need more output.”“We need shorter release cycles.”But speed isn't the real advantage of short sprints.The advantage is shortening the time between action and learning.A sprint isn't a delivery cycle. It's a feedback cycle.Each sprint gives a team a natural point to stop and ask: Did we build the right thing?Did we misunderstand the need?Are we still aligned with stakeholders?Are we learning what we hoped to learn?The shorter the sprint, the shorter the gap between assumption and validation.That's not about velocity. That's about reducing risk. Early Scrum teams often worked like this:Sprint, sprint, sprint… then release.That pattern made sense at the time in the 1990s and early 2000s. It was a huge improvement over what had come before. But it meant some feedback arrived in a big, delayed batch after the release.Over time, many teams evolved to:Sprint, release, sprint, release.And today, many modern teams have gone further still. They release whenever it makes sense—sometimes multiple times per sprint, sometimes many times per day.In other words, modern agile teams have largely decoupled sprints from releases.So if sprints aren't primarily about shipping anymore, what are they for?Sprints provide a reliable cadence for feedback and alignment—even when delivery happens continuously. Many organizations treat the Sprint Review as a demo.It's not.It's where reality gets a vote.The Sprint Review is where the team inspects what was built with the people who care about it, and adjusts course based on what they learn.When that meeting becomes optional, rushed, or performative, you don't just lose a ceremony. You lose your learning loop. And you start optimizing for finishing work instead of finishing the right work.If weekly feedback really is one of the biggest drivers of engagement and performance—as Gallup's numbers suggest—then the Sprint Review isn't overhead. It's how you reduce rework, prevent expensive surprises, and stay aligned with what actually matters. Of course, simply running one-week sprints doesn't guarantee meaningful feedback.Stakeholders can skip reviews.Teams can ignore input.The conversation can stay superficial.Short cycles create the opportunity for feedback. Leaders decide whether to use it.That's where the advantage lives.If you're running one- or two-week sprints, ask yourself:Are we using sprints as delivery deadlines—or as learning deadlines?Because the real power of agile isn't producing more every two weeks.It's learning more every two weeks.And that's a competitive advantage that will help you succeed with agile,How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

What Curling Can Teach Us About Agile - Mike CohnWith the Olympics underway, I've been watching a few events I don't normally pay much attention to—like curling.At first glance, curling looks almost comically simple. Someone slides a stone down the ice. A couple of teammates run alongside it frantically sweeping the ice with brooms. The stone glides… and somehow ends up exactly where they want it.But the more you watch, the more you realize curling isn't about making a perfect throw.It's about making adjustments after the throw.And that's what makes it a great analogy for agile.For a long time, traditional software development treated projects as if teams only had one chance to get everything right. The goal was to write the requirements document, create the design, then implement everything exactly according to plan. If you did enough planning up front, the thinking went, you could get it right the first time.The problem is that software development rarely works that way.Even if you have smart people and a solid plan, you're still operating on uncertain “ice.” Customers don't always know what they need until they see it. Stakeholders often describe what they want in ways that are incomplete, or ambiguous, or shaped by assumptions that turn out to be wrong. And developers—no matter how experienced—can misunderstand what they hear.That's not incompetence. That's just reality. Communication has friction. Uncertainty is built in.In curling, the team knows that too. They can't control the ice. They can't assume the stone will behave exactly the same way every time. Conditions vary. The surface isn't perfectly predictable. If the players just stood there and watched the stone slide, hoping it ends up in the bullseye, they'd lose most of their matches.So instead, they sweep.Sweeping doesn't completely change the outcome. It doesn't teleport the stone to the target. But it nudges the stone's speed and direction. It helps the team adjust to what's happening in real time.That's what agile does for software development.The plan is like the initial throw. It matters. You need to aim. Once the stone is moving, you don't get to stop everything and start over—you can only respond. But agile recognizes that aiming once isn't enough.The best teams don't aim once—they keep aiming.They build something small, show it, listen, learn, and adjust. They use feedback to steer the product toward what users truly need—not just what they said they needed, but what they meant. The known needs and the unstated ones.In other words, agile isn't about getting everything right up front.It's about staying close enough to reality to make course corrections while they're still cheap.One of the biggest mindset shifts agile asks of us is to stop treating change as failure. In the old model, change meant the plan was wrong. It meant rework. It meant someone made a mistake.But in agile, change is often a sign that learning is happening.Curling teams don't apologize for sweeping. They don't view it as an admission that the throw was bad. Sweeping is part of the game. It's what turns a decent throw into a great result.Agile teams do the same thing. They don't just launch work and hope it glides perfectly to the finish line. They inspect, adapt, and steer as they go.That's how you succeed with agile.And in the meantime, enjoy the Olympics.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

AI can make teams faster. But it can also quietly make them worse. In this episode, Brian Milner and Hunter Hillegas dig into the risks no one wants to talk about—from eroding developer judgment to weakening team communication—and what healthy teams should do about it.   Overview AI tools are powerful. They can generate code, draft tests, and accelerate delivery in ways that felt impossible just a few years ago. But speed is not the same as effectiveness. In this episode, Brian sits down with Mountain Goat Software CTO Hunter Hillegas to explore where AI may actually be hurting Agile teams. They discuss the risk of losing junior developer growth paths, the illusion of productivity through inflated metrics, the danger of outsourcing judgment, and how AI can quietly create communication silos inside Scrum teams. This is not an anti-AI conversation. It is a practical one. You will hear what guardrails healthy teams should consider, why accountability still belongs to humans, and how to use AI as a tool without letting it reshape your culture in ways you did not intend. If your team is leaning into AI, this episode will help you do it with your eyes open.   References and resources mentioned in the show: Hunter Hillegas Blog: AI Doesn't Eliminate Agile Teams — It Increases the Need for Great Ones by Mike Cohn #169: Building Practical AI for Agile Teams with Hunter Hillegas #82: The Intersection of AI and Agile with Emilia Breton #151: What AI Is Really Delivering (and What It's Not) with Evan Leybourn & Christopher Morales Mountain Goat Software Subscribe to the Agile Mentors Podcast    Want to get involved? This show is designed for you, and we'd love your input.   Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.   Got an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.  Hunter Hillegas is the Chief Technology Officer at Mountain Goat Software. With over 20 years of experience in software development, product ownership, and team leadership, he leads the creation of tools like the AI Toolkit and Team Home to support effective, engaging learning experiences. Hunter lives in Santa Barbara, California, with his wife and their dog Enzo.

How Much Are Meetings Hurting You? - Mike CohnI'm emailing because we keep seeing the same issue surface in different organizations, even where teams are experienced and committed.If something isn't working, it will usually show up in your meetings first. That's because work habits show up in real meetings, under real pressure.If planning, reviews, retrospectives, and daily scrums aren't working, agile won't work. That's where priorities get set, decisions get made, and trade-offs happen (or don't).After seeing capable teams benefit from an objective view of their meetings, we designed:Meeting Observation & Recommendations (MOR) It isn't more training (many teams don't need ‘more' training; they need direction)It doesn't require your team to step away from workAnd it's not about catching people outIt's about removing the constraints that are holding your team back.You can read about how it works here: Meeting Observation & RecommendationsThis is a fast way to see what's actually getting in the way, and find out what to change next.If you're accountable for delivery and feel like agile should be helping more than it is, this might be worth a look.Agile Meetings Playbook: https://agiledad.com/documentsHow to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

How To Provide a Release Plan Without Losing Agility - Mike CohnStakeholders want to know what will be delivered, and when. Your team wants to stay agile. So how do you create a roadmap (aka release plan or milestone plan) without locking down every detail? I'm about to start on a road trip between Idaho and Colorado: a 16-hour drive. I know where I'm going, and my general route, but I don't know every turn I'll take — and that's fine.That's how agile teams should treat release plans and roadmaps.My route is a plan, not a promise. It's not set in stone. The turns I made and my ETA could change based on roadwork, traffic congestion, an opportunity for an exciting detour, or even a flat tire. The further the distance I have to travel, the more uncertainty I should expect.Agile plans are the same. We can't predict every eventuality, but we can provide a forecast. We can provide a general idea of where we are planning to go, a predicted range of when we will likely hit key milestones, and our confidence level in the plan. Most agile teams know there's too much uncertainty to make guarantees. At the same time, they feel like a guarantee is the only thing stakeholders will accept.Here's what agile teams might be missing: Stakeholders have their own plans to make. And they are just as worried about being held accountable to their predictions as teams are.Stakeholders need accurate delivery dates and milestones (note I didn't say precise). They crave predictability.Sometimes it might feel like they're asking for a guarantee. But in truth, the only way to give them absolute certainty is to Overpad your estimates (like me telling someone my 16-hour drive will take 24, just in case), orRefuse to adapt when conditions change. Neither is good for the product, or the team. So what can you do when a stakeholder seems to want a guarantee vs a forecast? Try this: Talk to stakeholders in terms they understand.Here's one technique I've found helpful:Compare their request to requests for similar forecasts in their own domain.For example: Ask a salesperson what their comfort level would be if they were asked to guarantee exactly how much they'll sell — and which customers they'll close — in each of the next six months, or in the first year of a product's release.Ask a marketing person what their concerns would be if asked to commit to specific campaign results with exact timelines.Don't be confrontational. The point isn't to trap them — it's to show that uncertainty exists everywhere, and that agility is a strength, not a weakness. Then, share my road trip analogy with your stakeholders. Tell them that you can't give them a guarantee, but you can present a roadmap that looks ahead 3-6 months. The roadmap will show the team's goal, how much progress you believe you can make by when (expressed as a range), and your team's confidence in the plan.  Need help communicating your plans? Try our Plan Visualizer Tool, free for all MGS Essentials members.   Remind stakeholders that, like suggested routes on a long trip, agile roadmaps provide visibility, align expectations, and help people plan — without pretending every turn is known in advance.Freeing your team from unrealistic expectations can accelerate their move from good to great.A roadmap is a plan, not a promise Why stakeholders push for guarantees  The path to alignment starts with empathy Give stakeholders what they need to succeed How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Estimating can bring out strong reactions, and for good reason. Mike Cohn and Brian Milner unpack why it gets misused, what “estimate responsibly” really means, and how to use planning to make better decisions without turning numbers into weapons. Overview In this episode, Brian sits down with Mike Cohn to talk about estimating and planning in a way that teams can actually live with. They explore why estimates became such a hot button topic, what the “no estimates” movement is reacting to, and how Mike's thinking has evolved over time. You will hear practical guidance on story points versus time, why teams should estimate only when it helps someone make a decision, and how to keep estimates from damaging trust. They also cover where flow metrics help, where they fall short, and how teams build credibility with leadership through responsible planning. References and resources mentioned in the show: Mike Cohn Estimating & Planning in Agile - A 2026 Field Guide Accurate Agile Planning Course Blog: Estimating and Planning in Agile: Why They Still Matter in 2026 by Mike Cohn Blog: Getting Better Estimates Is Easier Than You Think by Mike Cohn Blog: What Are Agile Story Points? By Mike Cohn Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we'd love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Why Soft Skills Outlast Technical Skills on Product Teams - Mike CohnAnyone who has worked in product development for more than a few years has seen the same pattern repeat itself.The technical skills that once felt essential gradually—or sometimes suddenly—become obsolete. Tools change. Frameworks fall out of favor. Architectures that once seemed modern start to look dated.This isn't new, but it is accelerating.The half-life of technical skills keeps shrinking, especially in technology. In the 1980s, it took ten years for half of what you knew to become outdated. Today, it is four years, and will soon fall below two years according to a Stanford professor. This raises an important question for leaders:Where does investment in people have the greatest long-term impact?Technical skills are necessary, of course. But they are rarely durable.Soft skills behave very differently.When someone learns how to collaborate well, make good decisions, facilitate discussions, or lead others, those skills don't decay at the same rate. Instead, they tend to compound. They become part of how that person works.Learning how to learn is a good example. Once someone develops that capability, it stays with them. The same is true for decision-making, leadership, and collaboration. These are skills that can continue to improve over time—but they don't become irrelevant.I once saw just how important this was during a demo to a group of nurses.A programmer demonstrated new functionality and showed text on the screen that suggested giving Saltine crackers to a newborn—clearly clinically inappropriate.He tried to explain that it was just placeholder text. The real point, he said, was the workflow, not the words.But to the nurses, the words mattered a great deal.Their professional identity is grounded in “do no harm.” What they saw on the screen violated that principle. They were ready to escalate the issue and cancel the project.What saved the project wasn't a technical fix.It was the project manager's soft skills.He calmed the situation, acknowledged the nurses' concerns, explained what had happened, and persuaded them to come back a week later for a revised demo.The failure wasn't technical—it was a failure of empathy.Product development is full of uncertainty. We work with evolving requirements, incomplete information, and users whose trust we must earn and keep.Soft skills reduce risk in these environments.Empathy helps teams understand users. Clear communication builds trust. Collaboration prevents small misunderstandings from becoming major setbacks.And when these skills improve, the benefit isn't limited to one person.If someone learns a new technical skill, that benefit often stays with them. But when someone learns to collaborate better, the entire team benefits. Everyone gets better.This is one reason leaders often underestimate the return on investing in soft skills.The payoff isn't always immediate or easy to measure. It tends to show up most clearly under pressure—when teams need to have hard conversations, discuss options honestly, and make good decisions quickly.That's also when the absence of soft skills is most costly.Some leaders think these skills can wait until things slow down. In reality, pressure is when they matter most.Teams with strong soft skills can disagree productively, make tradeoffs together, and move forward with confidence—because trust was built earlier.Everyone on a product development team benefits from strong soft skills, but some roles depend on them especially heavily.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Using AI to Go From User Insight to Better Backlogs - Mike CohnAI is rapidly changing how product teams work—but the biggest opportunity isn't replacing product thinking. It's reducing the friction between understanding users and turning those insights into high-quality backlog items.To make the ideas concrete, I use a consistent example throughout: a team building software for valet-attended parking garages, initially selling to independent operations like boutique hotels. Each step builds on the previous one, showing how AI outputs can feed naturally into your existing agile practices.With a straightforward prompt, AI can help you build a detailed persona—including hopes, concerns, emotional triggers, and decision criteria. In my example, the persona that emerged was a garage owner/operator with high staff turnover, contract-renewal anxiety, and a strong desire for predictable labor costs. Several of these insights are things I might have missed or deprioritized on my own.Understanding a persona's aspirations—not just their functional needs—turns out to be especially valuable. Once a persona exists, you can ask AI to role-play that person and let you interview them. This is not a replacement for real user interviews, but it's a great way to explore assumptions, test questions, and uncover gaps in your thinking.AI is also excellent at preparing interview guides for real users who match a persona. With the right prompt, it can generate a structured guide that covers: Opening context (confidentiality, purpose, time commitment)Current workflows and pain pointsDesired future state and success criteriaConstraints (including regulatory or operational)Thoughtful wrap-up questionsLooking at the results, I was struck by how much better prepared I could have been for many interviews over the years if I'd had this kind of support. Once you're ready to move into backlog work, AI can help generate user stories and job stories that follow well-established agile guidance.By being explicit in the prompt—format, INVEST criteria, and output rules—you can get clean, ready-to-use stories that are easy to import into a backlog tool. AI can also correctly choose between user stories and job stories depending on whether the situation or the role is more important.In the valet parking example, this resulted in stories about vehicle handoff tracking, damage-claim protection, wait-time monitoring, staff accountability, and remote visibility into operations. I prefer to add acceptance criteria as a separate step, and AI handles this easily. You can ask for: A simple bullet list (great for user reviews), orGherkin (given-when-then) format for more formal specificationYou can even convert between formats later. Either way, this step quickly raises clarity and testability. AI isn't just for generating content—it's also useful for critique.With a structured prompt, AI can evaluate user and job stories against the INVEST criteria, identify only what's missing, explain why, and suggest a focused improvement. This works whether the stories were written by AI or by you.Over time, you can even build a library of good and bad examples to further improve the quality of feedback you get. AI won't replace talking to users, making judgment calls, or exercising product sense. What it can do is help teams move faster from vague ideas to concrete artifacts, surface blind spots, and raise the baseline quality of their work—especially when time or experience is limited.Used well, AI becomes a tireless collaborator: one that remembers persona details, never gets impatient with rewrites, and can move effortlessly from big-picture thinking to precise backlog items.The key mindset shift is this: don't ask whether AI can replace parts of product discovery or backlog refinement. Ask how it can help you arrive better prepared for the conversations that still matter most.

Start The Year With a Clean Backlog - Mike CohnThink outside the box.Do you hate that phrase as much as I do?It's become another overused business cliché, and it bothers me for another reason: Creativity often comes from thinking inside the box.This is especially true in agile story-writing workshops. The difference between a successful story-writing workshop and one that fails to deliver often comes down to a single factor:Whether or not the product owner defines a clear, significant objective: a “box” within which the team can think.Workshops without boundaries often roam across the entire product. Teams may generate a long list of user stories but those stories lack cohesion or purpose. They're hard to prioritize, and even harder to act on. The most productive workshops start with a simple framing statement from the product owner, like: “We're here to think about this specific subset of the product.”That's it. One well-chosen boundary and suddenly the team is aligned, focused, and generating better, more valuable ideas.Early in the product's life, that boundary might be about identifying what's needed to deliver an MVP.Later on, it might center around a Minimum Marketable Feature (MMF), something small enough to ship but valuable enough to matter. When workshops are focused around a meaningful objective, you don't need to hold them every sprint. I typically run them about once a quarter because one well-run session generates a steady flow of high-value stories.As this year closes and a new one begins, it's a great time to schedule a story-writing session. You might even want to bring our trainers in for a Story-Writing Workshop, where we'll work with you to: Set powerful, objective-based boundariesWrite stories that are right-sized and ready to buildBuild a focused backlog that everyone can align around Discover how to kick off the new year with a backlog that's ready to go.Whether you hold your own story-writing workshop or bring us in to help, remember that thinking inside the box is a powerful way to take teams from good to great,How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

AI Doesn't Eliminate Agile Teams — It Increases the Need for Great Ones - Mike CohnEveryone today seems eager to talk about how AI is accelerating software development. Teams are shipping faster. Individuals are more productive. Entire backlogs can be written in minutes. Estimates are a click away. Code that once took days now materializes in minutes. With all this newfound speed, it's understandable that teams and leaders start asking whether they still need the same kinds of collaboration—or even the same kinds of teams.Yet hidden underneath all that enthusiasm is a risk that hasn't received enough attention. In fact, I would argue it is the risk that agile leaders should be paying the closest attention to.https://www.mountaingoatsoftware.com/blog/ai-doesnt-eliminate-agile-teams-it-increases-the-need-for-great-onesHow to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Most agile transformations start with energy, and then stall out when things get complex. In this episode, Mike Cohn returns with a practical framework to help teams and leaders spot what’s missing, build lasting momentum, and navigate change with more clarity and intention.

Want To Win Big? Focus Small - Mike CohnSomething momentous happened on December 20, 2020.Becky Hammon made history as the first woman to ever coach a men's team in a National Basketball Association professional game. Coach Hammon took over coaching the San Antonio Spurs when head coach Gregg Popovich was ejected in the first half.After the game, the press asked Coach Hammon what her thoughts had been when her glass-ceiling-busting moment arrived. She said, “Honestly, in the moment I was just trying to win the game. I say this a lot, but I try not to think about the huge picture and the huge aspect of it, because it can get overwhelming.”I love this attitude. Yes, Hammon was busting through a glass ceiling. And yes, winning the game is the big goal for her and her players. But she also knew that their best chance of winning was to focus on the short term and execute well, play by play. It's easy for teams–sports teams and agile ones–to get distracted by how much is riding on the outcome of their endeavor. However, great teams (and their coaches) know that the path to success is achieved one small, well-executed step at a time. For example, some teams stall—thinking they need to have a perfect and complete product backlog written before starting a project. The perfect, complete product backlog doesn't exist. And, if it did, it could only be written once the project is finished! I advise these teams to reframe the question. These teams are trying to answer the question, “What should we build overall?” They instead need to consider, “What should we build next?”Similarly, organizations stall in their agile adoption efforts waiting for the perfect project or the perfect team of people to become available.Or they try to map out every step they'll take on an agile transition.I worry these organizations have a Gantt chart covering their agile transition hanging on a wall somewhere.As with a team trying to write a perfect product backlog, an organization waiting for perfect conditions to go agile is asking the wrong question. And now for what famed radio host Paul Harvey called “The Rest of the Story.”When Coach Hammon's big moment arrived in 2020, the Spurs ultimately lost the game. And that's OK. You don't win every game you play or make every shot you take.But you know what Coach Hammon did in 2022? She led the Las Vegas Aces to their first WNBA Championship. Then did it again the year after that, making the Aces the first WNBA team in 20 years to repeat as champions in back-to-back years.Be like Coach Hammon. Focus on the next thing that needs to be done while keeping the ultimate goal in mind. When you do, you maximize your chances of taking your own teams from good to great,Success Doesn't Happen OvernightHow to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Be Here Now - Mike CohnOne of my favorite books is one I've never completely read. It's called Be Here Now. A friend's older brother was reading it when I was 10. He let me page through his copy.The book caught my attention because it was square, an unusual shape for a book. Many of the pages inside the book were hand-lettered and illustrated.I next came across the book when I was a college freshman. I read part of it then but never finished it because it's a guide to Hinduism for Westerners, which isn't my thing.But the title of that book has always resonated with me: Be Here Now.I think the ability to be here now is something too many of us are losing. We can't just be in the moment and in the place. Everyone has to be constantly on their mobile phones. We multitask between what we should be working on and whatever else catches our eye, meanwhile listening for the assorted dings demanding attention.(I admit to having paused once even while writing this to investigate the boing of a new email arriving. But I've so far withheld the temptation to look a second time.)I witness the inability to be here now while training or working with teams. Once, during an in-person class, I was unable to make eye contact with any participant. Each was banging away on a laptop.When they asked questions, they were like, “When does the sprint master help with the project backlog?”Am I any better, though? I love music and grew up listening to the three-minute rock songs of the era. I remember listening to Beethoven's Ninth Symphony as a teen. It was OK (don't judge me!) but I thought, “Who has time for a one-hour song?”Now I hit skip halfway through my favorites on Spotify.I worry about attention spans and the ability to focus. The inability to be here now must have an impact on innovation, productivity, and teamwork. I don't have a solution.I don't have ”three quick tips to be here now.” I merely want to request that we each try to be here now a bit more often, a bit longer, and a bit more intensely each day,How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Why Teams Matter More Than Ever for Innovation - Mike CohnA few years ago, I worked with a product team that was stuck.They were smart, experienced, and deeply committed to building something meaningful. But despite their talent, their work felt...flat. They were completing tasks, but they weren't creating anything truly innovative. They weren't challenging each other's thinking. They weren't imagining possibilities beyond the obvious ones.Then something shifted.During a planning meeting, someone asked a question that reframed the whole discussion: “What problem are we really trying to solve?”That question sparked a debate — a lively one — and within minutes, the room was buzzing with ideas none of them had considered before. They envisioned possibilities, challenged assumptions, pushed each other, and built on each other's thinking. By the end of the meeting, they had the beginnings of a breakthrough.What changed?Not the people. Not the tools. Not the process.What changed was the team, acting like a team again — sharing purpose, curiosity, and creativity.And that's when I was reminded of a simple truth:Real innovation happens when people think together.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

We're doing Scrum. Why does everything take so long to finish?For many teams, delivery bogs down because of the way individuals approach the work itself.Most teams are still working in a sequence: one person finishes their part, hands it off, and then the next person begins. Designers wait for analysis to finish. Developers wait for designs. Testers wait for the code to be done. Everyone's optimizing for their own efficiency — but the team as a whole slows down.That might feel to individuals like the “right” way to work, but it comes with real costs: Mistakes go unnoticed until late in the process — and keep happening until then.Too much work is started toward the end of the sprint, creating bottlenecks and delays, which means features take longer to reach your users, and feedback takes longer to reach the team.Time to market, or time to value, is extended.Even when teams are doing “agile” on the surface, these large handoffs are the opposite of how an agile team works.To deliver value quickly, team members have to learn to stop waiting for someone else to finish before they start–in other words, they need to overlap work.When one type of task looks like it's dependent on another type of task, teams accustomed to overlapping work find ways to begin the second task before the first is completed. Coders start coding while the designer is still designing. Testers start creating tests even while the coder is coding.Why do teams cling to this outdated way of working?When teams first try working this way, many team members resist it. They're used to holding on to their work until it's perfect and “ready.” They might find the idea of overlapping work to be too messy and inefficient.Consider, for example, a tester. To be as efficient as possible, this tester would like to begin testing only after coding is complete. To test any earlier risks repeating work by re-running, or even re-designing, tests.What these team members need to realize is that optimizing for the efficiency of any one role prolongs the amount of time it takes to complete each new feature. Overlapping work is key to working in an agile way.For example, imagine that a developer is building a search results page for an eCommerce site. The page allows users to filter results by product attributes such as size, color, and more. Results can also be sorted by price, popularity, rating, and so on. If a programmer develops all of that before handing it over to a tester then no work has overlapped.If, however, the programmer handed it to the tester in pieces then testing could overlap with programming. The programmer could, for example, provide the tester with a version of the page without filtering or sorting. While a tester checks that, the developer adds filtering by size. Then color. Then sorting. The work overlaps — and everything moves faster.Two simple ways to encourage this way of working:Ask teams to shrink task size. Breaking big tasks into bite-sized pieces makes it easier for roles to overlap and collaborate. As handoffs get smaller, collaboration gets easier.Try swarming. Swarming is an extreme form of overlapping work that helps teams learn to let go of a “my work, your work” mindset and sequential “finish-to-start” mentality. When a team swarms, the whole team focuses on just one (or maybe two) items at a time.I'm not suggesting swarming as a long-term solution or the optimal way to work. It's a temporary, artificial constraint on work in process designed to force teams to find new ways to collaborate and move faster together. The goal is to remove the limit later, and have team members continue to apply the lessons they learned when they were forced to over-collaborate.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Are You Protecting Your Team Against the Right Thing? - Mike CohnA lot has been written and said about the responsibility of a Scrum Master to protect the team.Examples of protecting the team typically involve running interference with well-meaning but overzealous product owners, stakeholders, and managers. Teams run into trouble all the time from people who want it all now or who keep adding more work in the middle or a sprint. Scrum Masters keep all that noise away so that the team can focus on delivery.But if you are only focused on problems coming from squeaky wheels, you're missing one of the biggest dangers out there: complacency.Agile is about continually getting better. I don't care how good a team is today; if they aren't better a year from now, they're not agile.Complacency can creep in when a team sees some initial improvement from adopting an agile approach. Team members will notice how improved they are and think that's enough.But there's almost always room for further improvement.Some teams become complacent about their process and stop looking for ways to deliver more value each iteration. Still other teams become complacent in seeking out new engineering practices that could make the team even better.Protect your team from complacency by setting high expectations and encouraging the team to set even higher expectations of their own performance.Teams that refuse to settle for the status quo are teams that advance from good to great.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Can teams pull in more work during a sprint? - Mike Cohn“Can we bring in more work if we're ahead in a sprint?"It's one of the most common questions I get from Scrum teams — and honestly, for a long time, I couldn't understand why. The answer felt obvious.Of course you can bring in more work if you're ahead and clearly going to finish everything you committed to do. Just like you can drop work if you're behind.A sprint plan is a forecast — a best guess at what the team thinks it can get done. It's not a contract. No one gets it perfect every time, and that's OK.But I kept hearing this question over and over, so I started asking why. Why does adding work spark so much hesitation — even fear? Here's what I learned: Teams are afraid that starting something they can't fully complete within the sprint is somehow breaking the rules, or even worse, a failure.That fear leads teams to hesitate to pick up something new unless they're 100 percent sure they can finish it before the sprint ends.Let me reassure you. Being halfway done with one or two things at the end of a sprint isn't a problem. Sometimes, it's even desirable.It only becomes a problem if a team is consistently halfway done with several things or worse, everything.If the team is genuinely ahead, and they've completed what they committed to, they can absolutely pull in something new — even if they might not finish it.Good agile teams always try to finish everything, just like good sports teams try to make every attempt on goal or get a hit at every at bat.And when given the opportunity, great agile teams don't hesitate to make progress on something new even if they might not finish.What's the real issue underneath the question?How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Is your team moving in sync—or spinning in circles? - Mike CohnEver feel like your agile team should be working smoothly—but something's just a bit off? Handoffs feel clunky. Meetings drag. Even small changes spark big debates.It's not that your team isn't skilled—it's that you're not quite in sync.Rowers have a word for the alignment you're seeking: swing.What is swing?In crew rowing, swing is that near-magical moment when every rower moves in perfect unison—each stroke in sync, each effort amplified. And I do mean perfect unison. This means each rower: puts an oar into the water at the exact same timepulls for the same time and distance at the same speedlifts the oar out of the water at the same timeslides forward at the same paceTeam members hand off work frequently, without fanfare, and in small chunks.Team members can finish each other's… (Did you try to finish my sentence for me?) work. They can jump in and pick up tasks if someone is out sick or on vacation.Meetings are short, focused and valuable.Goals are ambitious, but usually met. When the team falls short, everyone (including leaders) understands that goals are not guarantees.A try-it-and-see mindset permeates the team. They're willing to experiment with new practices (such as user stories vs. job stories or story points vs. time) or frameworks (Scrum, SAFe, Kanban).The team is confident in their ability to succeed. As they deliver more and more value, and achieve outcome after outcome, the team feels almost unstoppable. Team members have fun. I sometimes decry that work is called work. I sincerely want work to be fun. I'm not naive: I know that won't always be the case. But when a team is working together well, it is fun.Swing is rare. When I rowed, our boat might have gone an entire race without once truly achieving swing. (And yes, it was usually my fault. Thanks for asking.)But when it happens, it's effortless. The boat flies.Agile teams can experience the same kind of swing. When everything starts to flowWhen teams are aligned and in sync you'll know it: ​​​​​None of this happens by accidentAchieving all of this isn't easy.Like rowers chasing swing, agile teams have to practice, reflect, and adjust—over and over again—in their quest to go from good to great.But take it from me, when it clicks, it's magic.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Are You Protecting Your Team Against the Right Thing? - Mike CohnA lot has been written and said about the responsibility of a Scrum Master to protect the team.Examples of protecting the team typically involve running interference with well-meaning but overzealous product owners, stakeholders, and managers. Teams run into trouble all the time from people who want it all now or who keep adding more work in the middle or a sprint. Scrum Masters keep all that noise away so that the team can focus on delivery.But if you are only focused on problems coming from squeaky wheels, you're missing one of the biggest dangers out there: complacency.Agile is about continually getting better. I don't care how good a team is today; if they aren't better a year from now, they're not agile.Complacency can creep in when a team sees some initial improvement from adopting an agile approach. Team members will notice how improved they are and think that's enough.But there's almost always room for further improvement.Some teams become complacent about their process and stop looking for ways to deliver more value each iteration. Still other teams become complacent in seeking out new engineering practices that could make the team even better.Protect your team from complacency by setting high expectations and encouraging the team to set even higher expectations of their own performance.Teams that refuse to settle for the status quo are teams that advance from good to great.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Karim Harbott: Why System Design Beats Individual Coaching Every Time 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.   "You can't change people, but you can change the system. Change the environment, not the people." - Karim Harbott   Karim was coaching a distributed team that was struggling with defects appearing constantly during sprints. The developers and testers were at different sites, and communication seemed fractured. But Karim knew from experience that when teams are underperforming, the problem usually isn't the people—it's the system they're working in. He stepped back to examine the broader context, implementing behavior-driven development(BDD) and specification by example to improve clarity through BDD scenarios.  But the defects persisted.  Then, almost by accident, Karim discovered the root cause: the developers and testers were employed by different companies. They had competing interests, different incentives, and fundamentally misaligned goals. No amount of coaching the individuals would fix a structural problem like that.  It took months, but eventually the system changed—developers and testers were reorganized into unified teams from the same organization. Suddenly, the defects dropped dramatically. As Jocko Willink writes in Extreme Ownership, when something isn't working, look at the system first. Karim's experience proves that sometimes the most compassionate thing you can do is stop trying to fix people and start fixing the environment they work in.   Self-reflection Question: When your team struggles, do you look at the people or at the system they're embedded in? Featured Book of the Week: Scaling Lean and Agile Development by Craig Larman and Bas Vodde "This book was absolute gold. The way it is written, and the tools they talk about went beyond what I was talking about back then. They introduced many concepts that I now use." - Karim Harbott   Karim discovered Scaling Lean and Agile Development by accident, but it resonated with him immediately. The concepts Craig Larman and Bas Vodde introduced—particularly around LeSS (Large-Scale Scrum)—went far beyond the basics Karim had been working with. The book opened his eyes to system-level thinking at scale, showing how to maintain agility even as organizations grow.  It's packed with practical tools and frameworks that Karim still uses today. For anyone working beyond a single team, this book provides the depth and nuance that most scaling frameworks gloss over. Also worth reading: User Stories Applied by Mike Cohn, another foundational text that shaped Karim's approach to working with teams.   [The Scrum Master Toolbox Podcast Recommends]

The Only Three Things You Must Do To Improve Agility - Mike CohnDistilled to its essence, it's quite simple to be a Scrum Master, agile coach, or anyone seeking to improve team or organizational agility. There are only three things you need to do and Saint Francis laid them out succinctly over 800 years ago:  To improve agility, we have to start with what's necessary. Change practices that go against agile principles. If programmers and testers aren't part of a single multidisciplinary team, that needs to change.If the team doesn't see the benefits of iterative and incremental work, you need to talk to them about that.Similarly, if management is imposing deadlines without regard to the team's opinion, you'll need to help them see the light.  Having made changes necessary to enable agility, look next at what's possible. There will be many more options to choose from now, such as: Shortening iterationsImproving teamworkReducing handoffs by overlapping workIntroducing new practices such as story mapping or job stories“Start by doing what's necessary, then what's possible, and suddenly you are doing the impossible.” Doing What's NecessaryThen Do What's PossibleDon't try to improve too many things at once and choose wisely. Initially there will be opportunities for small changes to create outsize improvements. Finally, Do the ImpossibleAt this point, it's time to do the impossible . . . except that now very little is impossible.Having iteratively and incrementally improved, most teams feel powerful enough to take on challenges and changes that would have seemed impossible before.What still seem impossible are changes outside the team. Managers may still impose deadlines. Stakeholders may foist too-frequent changes because they've heard agile teams “embrace change.”Fixing these outside-the-team behaviors isn't impossible, but it is harder and often takes time. Fortunately a team that has done the necessary and then the possible will be ready to do the impossible.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Team Dynamics - The Soloist - Mike CohnIt's always great when a high performer joins a team. A true star can elevate everyone through their attitude, ability, and commitment.Think of them like a brilliant musician in a band—a lead guitarist or vocalist who's not just talented, but who listens, collaborates, and knows how to bring out the best in everyone else. They don't just shine—they make the whole group sound better.But sometimes, the high-performing teammate turns out to be more comfortable as a soloist.Soloists want to stand out—but often at the expense of the ensemble. They can sometimes play over others, ignore the rhythm of the group, and expect the spotlight on every track. They might be technically excellent, but they're out of sync.These kinds of high performers sometimes overvalue their individual contribution and subtly (or not-so-subtly) expect special treatment: the final say in decisions, the best projects, or freedom from feedback and constraints. When they take risks and things go wrong, they assume their talent will shield them—leaving the rest of the team to clean up after the show.The difference between a true bandmate and a soloist isn't skill—it's orientation. One makes the team tighter. The other plays their own set.That's where the Scrum Master comes in.A good Scrum Master notices when someone's out of sync and steps in early—before the rhythm breaks.Rather than act on their own opinion, the Scrum Master should have the private conversations necessary to confirm that the rest of the team also feels the soloist is throwing off their rhythm.If the feeling is widespread, then the Scrum Master should have a private conversation with the soloist about any behavior that is detrimental to the team. If, for example, a diva is ignoring what the team selected during sprint planning and instead chooses to work on pet projects, the diva needs to understand that's not acceptable.If a private conversation doesn't help, the Scrum Master can escalate the problem to the solist's functional manager. Consider including the soloist in that conversation so that there's no miscommunication and everyone is on the same page.Don't let one person throw off the rhythm of the whole team. To succeed with agile, we don't need virtuosos; we need great bands.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

How to Engage Busy Stakeholders - Mike CohnWe often find ourselves reliant on others outside the team.For example, an agile team may get stuck waiting for feedback on the latest features or input on what to build next because a key stakeholder has never shown up for a sprint review. Without that stakeholder's feedback, the team is impeded: unable to determine if what they've created is what's needed.The team nags, pleads, and cajoles. But still they're left waiting because stakeholders are often busy, and they just can't (or won't) find the time.You've tried moving the sprint review meeting to more convenient times. You've sent agendas that make it clear the stakeholder's most desired feature is the one being discussed in the review.But time and time again, something comes up at the last minute and the stakeholder is a no show.In these instances, it's time to take the meeting to them. When a stakeholder won't (or can't) show up for the team, it's time for a different approach: Schedule time on the stakeholder's calendar for a meeting a few days before sprint planning.Use that block of time to work together on what the team needs.Schedule a Non-Meeting Meeting Tip within the Tip: Want more help with team dynamics and stakeholder management? Try my free Scrum Team Reset training. It's three videos from me that will help you find new ways to take your team from good to great. When I schedule the meeting, I'll sometimes be very clear what the meeting is about: “I want to go over such-and-such with you before the review.” Other times, I'll be more vague: “I need to chat about the project.”Use whatever language you need to secure time on the person's calendar. Why? Because we are all more willing to cancel appointments with ourselves than we are to cancel an appointment with someone else. By putting time on their calendar that they're reluctant to cancel, you've secured enough time for them to actually do the work. Get the To-Do to DoneDuring the meeting, explain to them the work you need them to do (look at the feature and give feedback or clarify how the feature should work.) Then, use the time to step through the implementation (or plan) with them.This results in two things: the team gets the information it needs. The stakeholder finds that the thing they've been putting off really wasn't so bad once they focused on getting it done. Why This WorksWhen stakeholders show an inability to get work or answers to you at appropriate times, it's time to intervene. Maybe they're worried their time will be wasted in a review where their feature is one of many being discussed.Maybe “review the xyz feature” has been on their to-do list and keeps getting bumped down. Or maybe they haven't actually scheduled a specific time to work on it.No matter the reason, the work the team needs done is not happening. And your best chance of helping the stakeholder do that work is to schedule time with the stakeholder directly. And then use that time to make it happen.Should stakeholders be able to do this on their own?Sure.But we all struggle at times. My experience is that after doing this a handful of times with a stakeholder, most stakeholders will form a new habit and be able to continue without you.In other cases, you and the stakeholder will discover it actually is more efficient when done together, and you'll keep a recurring meeting on their calendar that isn't the review. That's perfectly fine, too.Stakeholders are often busy. And that can cause them to take longer to respond than a fast-moving agile team might like. Finding creative solutions that keep the team moving (even if it's not something Scrum prescribes) is the best way to help advance a team from good to great,How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Is it ever OK to deviate from the Scrum Guide? - Mike CohnI'm out there on social media and I see all the same posts you do about the sanctity of the Scrum rules. And I get it. There are many rules of Scrum that teams break when they shouldn't. But I don't think it does anyone any good to be so hung up on rules that you throw practicality out the window.Here's the thing: No team should break a Scrum rule before they've tried to do it by the book for a while, and given themselves a chance to understand why each rule exists in the first place.But teams that have been doing Scrum together for a while sometimes need to bend a few Scrum rules to fit their specific circumstances and situation. And in most cases no one needs to start calling foul if they do!Here are a few common rules most teams can safely break or bend:Never extending a sprint is a great rule. Usually. Can it be broken? Yes—not often and always for a good reason (such as a holiday that makes a longer sprint sensible).It's ideal to have a dedicated Scrum Master–it's the best way to build high-performing teams. But having a dedicated Scrum Master is an economic decision and it may not always be justified, especially once the team can take on some responsibilities for itself.Having a retrospective every sprint is a wonderful way to put improvement front and center. But if a team is running one or two-week sprints and things are going well, I think it's OK for them to only do a retrospective every four weeks (or every other sprint).Teams that are new to Scrum should do Scrum by the book. But it's unrealistic to expect teams to never bend or break a rule to better fit their context.Knowing when to follow the rules, and when to break them, helps teams succeed,How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Setting and Managing Expectations - Mike CohnMy first Scrum project was incredibly successful, yet it was almost a failure.All of the technical aspects of the project were going extremely well. We were ahead of schedule, stress and scalability tests showed that we'd exceed uptime and reliability goals. Everyone on the team was having fun and doing their best work.The problem was that user expectations had been growing faster than the functionality being developed.The project was call center software to be used by hundreds of nurses initially, scaling to thousands. Nurses would use the system to triage patients, provide advice, dispatch emergency personnel when needed and so on.In monthly sprint reviews with the nurse users, I was routinely shocked by what they'd come to expect, some of which wasn't even technically feasible. With about three months left on the year-long project, I realized my focus had to change. From then on, I spent almost all of my time on expectations management.I met with nurses in each of the call centers and described exactly what would and would not be in the delivered system. I toned down their expectations about the system's impact on world peace, global warming, and personal weight loss.Had I not done this, the product would have been perceived as a failure.Since that project, I have been acutely aware of the importance of expectations management to the overall success of any project. Setting and managing expectations is perhaps even more important when an organization seeks to adopt or improve its agility.With agile improvement efforts, I find it helpful to set and manage expectations about four things: How quickly teams will improveHow long it will take to gain additional predictability from the team's new way of workingHow there will almost always come a time when turning back looks easier than sticking with itThe level of involvement in the transition that will be necessary from various stakeholders and organization leadersBy properly setting expectations you can avoid the problem of having an otherwise successful transition or project sunk by unrealistic expectations,How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Is your team dreading retrospectives, or skipping them altogether? Mike Cohn joins Brian Milner to unpack what’s really going wrong (and how to fix it) so retros don’t just take up time… they actually make your team better.

Is Your Team Heading For a Win? It's officially the end of summer here in the U.S. Part of me is sad. Cooler temps mean it's time for me to hang up my wakeboard and store my boat for the season.But part of me welcomes the move to falling leaves, long sleeves, and Major League Baseball playoffs. I'm a big Dodgers fan, and I'm hoping they make it to the post-season again this year.But even if my team doesn't go, I'll still watch the playoffs and World Series–both because I'm a fan and also to see if I can predict the winning team. And while I'm no Nostradamus, I do have a bit of a superpower. After just one or two innings, I can often tell who is going to win the game.Why? Because it's usually clear that one team is trying just a little bit harder. They're not pitching any better or getting more hits–they're just more engaged.They're running down every foul ball, even when it's already crossed into the stands. They're moving toward every hit, only backing off when a teammate yells, “Mine.” From the superstars to the backup right fielder, everyone on the field is looking for ways to contribute, even when it's outside their role.It's a thrill to watch teams like this: Teams who have put their individual egos aside to win the game. I've seen the same thing happen with successful agile teams, too.Agile teams thrive when team members let go of their egos and do what needs to be done. Agile teams struggle when people stay too rigidly in their most comfortable role–a programmer who refuses to do anything but code or an architect who won't come down from the ivory tower to dirty his or her hands with actual code.The Best Agile Teams Operate without Ego“Agile teams thrive when team members let go of their egos and do what needs to be done.”I'm not saying that everyone needs to be a generalist–that would be like having your pitcher also play first base! What I am saying is if that first baseman has to field the ball, I expect the pitcher to hustle over and cover first to make the out. And if the testers are behind or someone has run into a roadblock, I expect to see anyone who is able help out.On high-performing teams, each person plays their part as best as they can, and looks for opportunities to back up their teammates when they need help.On these teams, it seems as if everyone starts each day thinking: “How can I best help the team win today?”When team members have a winning attitude, I'm willing to bet they're on the move from good to great.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Consider The Downstream Effects - Mike CohnHave you ever looked at the pipes under a bathroom or kitchen sink?If you do, you'll notice that the pipe doesn't run straight from the sink to the wall. Instead the pipe from the drain goes down farther than necessary, curves right back up and then heads into the wall.This little extra bit of pipe that goes down farther than necessary and u-turns back up is called a P-trap. That's because it looks like a P turned on this side.Why do plumbers install P-traps? They must cost more to manufacture, so it increases their costs, which they may or may not be able to pass on to customers. They're a little harder to install, so they cost the plumber time, too.So, why? Plumbers install P-traps because they prevent downstream problems. A P-trap under your sink traps gases that would otherwise rise back into the house. They also catch small items that fall down the drain.And good plumbers care about this even though they know they may not be the plumber to return to fix the problem.Good plumbers care because they're good plumbers. Installing a P-trap under your sink is simply the right thing to do because it prevents downstream problems. We want agile team members who behave the same way. Good agile team members care–not just about their own work but also about the work of everyone downstream of them. OK. Back to the example. A while back, I helped a team incorporate more automated testing into their work. Some programmers, who viewed their job as nothing more than writing what they considered good code, balked at the idea of altering their code to make future testing easier. Code testability, they argued, was not their problem; it was the testers' problem.The situation came to a head during a sprint planning meeting, when the testers were giving some really large estimates for testing code that was going to take only a fraction of that amount of time to program.The programmers were asked if they could do anything to make the code easier to test. And it turned out there were some things they could do, but some of the programmers didn't want to do them because they felt it would make their code less elegant.They had defined their jobs as merely writing good code. Who cared if that code was hard to test?Why Do Something If It's Harder?Act Like a Good PlumberI'm going to give you an example of why this matters, but first, I need a favor. Would you take this short AI survey?We want to learn more about how Agile teams are using (or thinking about using) AI in their work. Your input will help us better understand current practices, opportunities, and challenges—and we'll be sharing the results with the community.Take the survey here: https://www.surveymonkey.com/r/ZJY2SXY“They had defined their jobs as merely writing good code. Who cared if that code was hard to test?”If my plumber had done that, I would have had a fully functional sink, perhaps for years. But eventually enough debris would have made it past where a P-trap should have been installed and deep into my plumbing. This would have led to an expensive--and easily avoidable--repair.When team members accept responsibility for issues caused downstream of their work, that team can begin to grow from good to great.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Join Brian and Barnaby Golden as they dig into a surprisingly common roadblock in Agile teams, the underpowered product owner, and how it quietly derails decision-making, flow, and team momentum. Overview In this episode of the Agile Mentors Podcast, Brian welcomes Agile coach and community contributor Barnaby Golden to explore the risks and ripple effects of placing a product owner in the role without the authority to own it. They discuss the stark difference between empowered and underpowered product owners, why availability without authority is a setup for frustration, and how misalignment at the leadership level creates more theater than agility. From trust gaps to political decision-making, Barnaby and Brian unpack the hidden reasons teams get stuck and what it takes to create real, empowered ownership that delivers actual value. References and resources mentioned in the show: Barnaby Golden #104: Mastering Product Ownership with Mike Cohn #3: What Makes a Great Product Owner? With Lance Dacy How to Engage and Help Busy Product Owners by Mike Cohn What Happens When For Product Owners Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Barnaby Golden is an experienced Scrum Master and Agile Coach with a knack for helping teams truly live Agile, not just adopt it. Lately, he’s been diving into the real-world use of AI—helping organizations, including nonprofits, turn tech hype into practical, high-impact tools with smart governance Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors, we're back. This is another episode of the Agile Mentors Podcast. I'm here with you as always, Brian Milner, and we have a very special guest with us today. We have Mr. Barnaby Golden with us. Barnaby, welcome in. Barnaby Golden (00:14) Thank you, it's good to be here. Brian Milner (00:16) Very excited to have Barnaby here. Barnaby is an Agile coach, also a Scrum Master. He is known to us because he is part of our Agile Mentors community. And he is an active member there and has weighed in on several issues and helped people and mentored people through things there. So we wanted to share some of the wisdom of the crowd that we have there at Agile Mentors. Just a few select people that have really contributed. and giving us some really good advice there with the podcast audience as well. So you guys can kind of hear what kind of stuff is there on the Agile Mentors discussion forums. But we were talking about topics here with Barnaby about what we were going to talk about and he proposed one that I really found intriguing. It was focusing around the underpowered product owner, the underpowered PO. And I think that's probably a good place for us to start then, Barnaby. Why don't you kind of just explain to everyone what that idea is, what you mean by the underpowered PO. Barnaby Golden (01:12) Sure, of course. So in fact, what I'll do is I'll explain it by giving you the opposite, which is what does a good, effective, powerful product owner look like? And I was working for an organization a few years back, it was a publishing organization. And we had the head of the editorial team was the product owner for a particular Scrum team. Brian Milner (01:16) Okay. Barnaby Golden (01:38) And this head of editorial had a lot of power and influence in the organization. They were pretty much a decision maker in terms of the products that the team was building. And I remember a particular conversation where the team was talking to this product owner and the team said, look, we know you want to get this, this release out this week, but we've got some technical debt. really need to fix it. And I remember the, this guy saying, look, okay. I'm going to let me think about this for a second. Okay. I can make the decision on this, which is, yep, you can have your time. I'll communicate with others within the organization. The release will be delayed. And that was such a powerful moment because in that second, the decision was made. The product owner trusted the team, the team completely trusted the product owner. And it felt slick and efficient and worked really well. Conversely, I've worked in organizations where in some way, surprisingly enough, product owner is seen as quite a junior role. So I've seen the situation where you have a whole hierarchy of product people and the most junior role in the product organization is the product owner. And what happens in that scenario is the product owner is powerless to make a lot of decisions. So they have to push them up the tree. And in that situation, the conversation between the team and the product owner is the team says, yeah, we need to do this thing. And the product owner says, okay, give me some time. Might be a day and I'll get back to you. Hopefully I can get in contact with other people within my hierarchy and the flows broken. What's the team going to do now? They're going to maybe find something alternative to work on. It's very frustrating. And you sometimes get the situation as well where the the underpowered product owner will sympathize with something the team is saying, but will not be able to make a change because they haven't got the authority to do the change. So they'll say, yeah, I agree with you. I know what you're saying. This is a really bad idea what's being suggested, but I have no choice. We have a roadmap. We've got to meet the roadmap. Brian Milner (03:45) Yeah, that's a clear picture. I agree with you that those are two stark contrasts. And what I like about the explanation is you kind of highlight the effectiveness of one versus the ineffectiveness of the other, right? It's just, it's such a dramatic difference when that person is able to make the decisions on the spot. go forward, and the team is just free to move as quickly as possible. Whereas the other one, it's just holdups. It's just delays and obstacles, roadblocks in the team's way. So yeah, a really clear picture there. Just as you were talking about this, I was thinking to myself, well, maybe one of the worthy paths for us to go down here and talking about this. is trying to understand a little bit about the why behind it. ⁓ Because I think there's, just in thinking about it, I think there's maybe several causes for this or several things that might lead to having an underpowered PO. What's been your experience? What kind of things have you seen that might contribute to an underpowered PO? Barnaby Golden (04:36) Hmm. I think the main reason, the biggest driving factor behind it is the feeling that the people with the authority to make decisions do not have time to spend with the team. So you've got your head of product or the real decision makers in the organization. They are saying, I can't spend two, three hours a week with a team. I can't go to a planning meeting. got, you know, I'm a busy person. I've got things on my schedule. So they see the product owner role as a stand-in for themselves with the team. And this stand-in has lots of time to spend with the team, which is good. And that's a powerful thing. But at the same time, if they've not got the authority to make decisions, then maybe that time is not effectively spent. Brian Milner (05:41) Yeah, it's almost as if they just want a warm body there. It's a placeholder. You're here as a placeholder for me because I can't be two places at once. I've heard a couple of things that people will frequently point to that a product owner needs to be successful. And there's sort of this dichotomy of these two things that are part of that. And that's the kind of empowered Barnaby Golden (05:44) Yeah. Brian Milner (06:05) product owner that is empowered to make decisions versus having the availability to actually be present with the team. it's always, it seems like that's a fracture point that sometimes causes this because you have the leaders who, hey, I need to make all the decisions, but I don't have the availability. and the people that they know have the availability, they don't want to empower to make the decisions. So they're kind of setting up their product owners to fail. Barnaby Golden (06:35) I think it's a classic example as well with when you want to be an agile organization, you can't just have pockets of agility. You can't just have a scrum team and say, well, that's where we'll be agile in this scrum team. The entire organization as a whole has to think in the agile mindset. And if you want to be able to adapt to change, then one of the ways you're to have to do that is you're going to have to have the decision makers close to the teams that are implementing the decisions. and so you can't have your, your cake and not eat it. If you see what I mean in terms of, you, you can't pick and choose the aspects of agile that you want. need to, as an organization, adopt the whole thing. Brian Milner (07:17) Yeah, that's always one thing I try to tell people as well is when you're selecting a product owner, when you're trying to decide who's the right person to be the product owner for this team, those are two of the things you have to really consider strongly is does this person have the availability to be here with the team and is this person empowered to make decisions? I've run up against leaders before that don't want to empower someone and Kind of the counterpoint I give them a lot of times is, I don't know, I think maybe in their head they're thinking this is giving someone free reign to make really long-term decisions on their own when that's not really the case. The product owner can be fully empowered, but the decisions that they're making on the spot are just a couple of week decisions. It's not a six month decision. there's gonna be sprint reviews, we're gonna display stuff and get feedback and we can course correct and all those things. So once you can kind of put it in that frame that it's really just a couple of weeks that you're empowering them to make decisions, I've had more success framing it that way. I don't know, what about you? Barnaby Golden (08:23) Yeah, I think that makes a huge amount of sense. The fear is loss of control. So the fear is that by empowering the product owner, they might do something which they would regard as a mistake. And they will often see themselves, because they're in a senior position, they see themselves as being responsible. So if they're responsible and the product owner makes a decision they don't like, perhaps that will reflect poorly on them. So there's a trust issue here. A good product owner is going to be consulting their stakeholders anyway. And I would think the, the senior product leadership team is part of their stakeholders. So you would hope that they were keeping them very, very up to date on their thinking that there would be no great surprises that they wouldn't do something, you know, suddenly switch from one product to a completely different product. They would always be keeping their stakeholders in the loop. And in which case. they would be building up the trust of the people around them and then you would hope that over time that they would become more empowered. Brian Milner (09:23) Yeah. Yeah. I just, I kind of wonder if that's maybe part of it, that the, they have a misunderstanding of kind of how the role works. You know, cause maybe they, maybe they see it as completely independent. This person is just making decisions on their own without consulting anyone. Maybe that's because that's how they do their job. Barnaby Golden (09:35) Yeah. Yeah. Brian Milner (09:49) So they may look at that as, know, this is how I would do it, so why wouldn't this person do it the same way? Well, that's not how it's designed. It's designed to be done in concert. Barnaby Golden (09:59) Yeah, absolutely. Yeah, it's a misunderstanding of the product owner role. And it's also a misunderstanding of why the product owner role came about, which is the reason it was there was to solve the problem of too many chefs, of too many people trying to make decisions. So there's huge value in the role. But the value in the role only comes about if that person can actually take ownership of the product. I mean, the clue's in the name, isn't it? They are the owner of the product, so therefore they can make the critical on the ground decisions, but all the time talking to their stakeholders. So, I mean, as with many things in Scrum, it's about a misunderstanding, a general misunderstanding of what the roles are within the Scrum team. Brian Milner (10:41) Yeah, I think they also have the fear of the wrong decision that somehow that's going to lock them in or this person's not equipped to make the right decisions that they are the knowledge expert for the product. so they should be the one making all the decisions. They have the authority. I have had a couple of cases where I've had to have difficult conversations with leaders to say, well, let's examine the decision. because you're looking at them as making the wrong decision, but is it the wrong decision? You're disconnected from the day-to-day of the team. This person is fully connected to the day-to-day, and they're more likely to have more current knowledge. And it's not always the case that just because you assume it's the wrong decision that it actually is, they may actually be right and you could be wrong. Barnaby Golden (11:30) And funny enough, this brings on to another topic I'm greatly interested in, which is the definition of value. And that is if there is no clear understanding within the organization of value, then decisions become arbitrary. You know, we decide to do X rather than Y in the product. Well, why did you decide to do that? Well, because it was my decision to do that. Yeah, but is there a rationale behind it? Do you have a definition of the value of X and the value of Y? and why you chose one over the other. And I think that's part of the problem as well. The kinds of organizations that don't have empowered product owners also typically don't have a definition of value. Brian Milner (12:08) Yeah, I completely agree. I know I've had conversations in classes where I've talked to people about how when you're prioritizing, when you're looking at things in your backlog, and we always say you prioritize according to value. Well, what's the value? What's the value of doing that thing? And so many times, I think there are organizations that can't really identify what it is. Why are we doing this thing? because it sounded cool, because it seemed like the right thing to do, it just felt right? No, we're doing it so that it does something, it creates some outcome for us. And if you can't even really define what that outcome is that you're hoping it achieves, well, isn't that the start of the problem? Barnaby Golden (12:55) And I think part of the root cause of that as well is the tendency for these types of organizations to do long-term planning. So what they'll often do is they'll have a roadmap for the year and they'll say in this roadmap for the year, we will achieve all these things. And then it becomes less about delivering value and more about delivering the roadmap. And I've had conversations with product owners where I've said to them, you do realize what we're doing doesn't make sense. And they say, yeah, of course they do, but I'm not being measured. on sense or the delivery of value, I'm being measured on whether or not I meet the roadmap. And that was what's important to me. You can see how all these elements are tied together within the organization. Brian Milner (13:28) Right. Right? Yeah. No, that's an excellent point. And you're absolutely right. So much of our metrics and some of the things that we judge teams on or performance by is basically just a volume kind of metric. And it's how much stuff is being produced. that's not value. Volume does not equal value. Value can be achieved with much less a lot of the times. And if we're This is why sometimes I'll advise product owners in classes to say, look, start up your sprint review. Maybe go back and look at some things that you've done recently and show the metric that you're using for that thing to see if it's successful. Because if the team's done something in the past three or four sprints and it's actually moved the value needle some way, it's increased customer satisfaction. added new members to our site, whatever the thing is, right? If you can show that kind of business value to it, my experience is that people stop focusing as much on volume, because that's volumes of means to the end, which is the value. Barnaby Golden (14:40) Yeah. Yeah, absolutely. And the other thing I've noticed as well in these types of organizations is that the value they're focused on is the incremental, is not the incremental delivery. It's usually a new feature or something like that competing. And what you often find is that the teams are not end value creators. They're often parts of... the creation of value. rather than the whole creation of value, there may be a component of it. And because of that, people will say, well, there's no direct link between you and value creation in the organization. And I find that is very problematic. And it really flies against the rationale of Scrum, which is that you want within each sprint, you want to deliver some incremental value. And if you can't measure it, if you can't... clearly define what that value is. And as you were saying, if the product owner can't stand in the sprint review and say, well, this is the value we've delivered. How does the team keep motivated? How do they keep passionate about what they're doing? Brian Milner (15:50) Yeah. Yeah. I think part of that is just trying to put yourselves in the shoes of your customers and try to look about what they would find as being really valuable. I don't know about you. know, well, I'm sure this applies to you as well. But we all are consumers of different software products, whether that's a business software product or even games or other things that we would use. And when they come out with new releases of those things, they come out with release notes. Now, when they come out with the release notes, are you looking at the release notes and going, wow, I'm satisfied. There's a ton of things that's in this release. Or are you looking through the individual items and going, well, I don't care about that. I don't care about that. I don't care about this. That thing, oh yeah, that's important to me. Right? That's what we do. And that's a clear picture of value over volume. Barnaby Golden (16:49) Yeah, I mean, I think the thing that gets in the way here is a lot of it is the pride of the management team. So they often have strong self belief. They believe they make, they believe by definition, the decisions they're making are powerful decisions. So, I, it's also, think one of the reasons why a lot of organizations don't aren't data driven. You would hope they would. produce a feature and then measure whether or not that feature was a success. But that's not as common as it should be. There's very rarely business metrics tracked against deliveries. I mean, I'm generalizing here. There are many organizations do this very well. But I found there's quite a few organizations that don't really do that. And it leads to a disconnect with the customers. I mean, I can think of an example that we're... an organization I was working at where they worked on a feature delivery for six months that was on the roadmap and they got it done and they shipped it. And I think the expected users were tens of thousands and they got 16 users for this feature. And at that point there wasn't even a post-mortem. They didn't even look back and say, well, what are the lessons learned here? It was like, that's shame. Let's move on to the next item on the roadmap and hope that works instead. And it's very frustrating, especially because the feel of a good Scrum team is the connection with the customers and the feeling that you can see the passion in the engineers and in the team's eyes because they're delivering things that people want and they feel connected to it. And it means they work better and they work more effectively. Brian Milner (18:22) Yeah, there's no worse feeling than building something no one uses. I used to joke with the team, it's kind of like that old joke about if a tree falls in the woods and no one's around us, makes, if we build software that nobody uses, did we build it? It's not going to be used for anything. So it didn't serve any purpose. Barnaby Golden (18:31) You Yeah. Yeah, the way I like to think of it is that an organization should not view people's time spent in the job as important. What they should view is the value that that person has delivered as important. So sometimes people will say, know, yeah, okay, we delivered a feature that nobody really used, but you you did your job, you came in for eight hours a day during that time. And that's hard for people, I think, because they feel like this is my life. I'm investing time and energy into this. Yeah, the money is important, of course. I'm doing it as a career. But at the same time, I also want to feel reward. I want to feel like I'm achieving something. And I think with that element, you get so much better performance from the team if they feel that. Brian Milner (19:26) I agree. There's another thing I was thinking of here too, when we were talking about underpowered POs. Another cause I think that maybe you've encountered or seen as well, but screwy things that people do with kind of personnel. Like for example, having multiple product owners for a team, that leads to underpowered product owner or the opposite even putting a product owner on too many teams. That's going lead to underpowered POs as well. What's been your experience with that? Have you seen that? Okay. Barnaby Golden (19:54) I have one extreme example where there was an engineering team and the organization was an international organization. And politically within the organization, it was unacceptable to have one backlog. They had to have a backlog for the UK, a backlog for the US, a backlog for Australia, backlog for other areas of the world. And the team then had to... prioritize them kind of in this wild order. So they would say, right, we'll take number one from UK, number one from US. And so there was no coherence to what they were building at all. It was really just about satisfying people within the organization. And it kind of brings you back to that key point about why do we have product owners? Because product owners, they narrow down all the ambiguity, they narrow down all the possibilities to the thing that's most effective for the team to do next. Brian Milner (20:47) Yeah, I like your example because it highlights kind of what I think about those scenarios a lot of times is that they're theater. They're an act. They're not really serving the purpose, but they're making someone or helping someone to feel a sense of security about something that really they shouldn't feel. It's not there, but it has the appearance of it. It has the stage set. Barnaby Golden (20:55) Hmm. Yeah. Brian Milner (21:11) of something that looks secure, you know? Barnaby Golden (21:13) Yeah. mean, whenever somebody mentioned that to me, the first thing I always think about is the length of the backlog. I've worked in organizations where they could not achieve the backlog in 10 years if the team kept at it. And yet people within the organization say, yeah, I'm not worried. My feature request is on the backlog. And I'm thinking, yeah, but we're adding 10 new items a week and we're only completing eight. So in fact, you're moving further down the backlog. You're not actually getting closer to. being done. And it's, it's, it's a disconnect to gain. And this is what it's all about. Good agility, good scrum is when there's a strong connection. And if you start having that, that just doing things for appearances sake, then you lose that connection. Brian Milner (21:55) Yeah, and it really is kind of that fundamental flaw that we try to address throughout Scrum of transparency. When you do those kind of theater-ish things to give the appearance of something, it's the opposite of being transparent. You're trying to make it more difficult to see the reality. Yeah, it's on the backlog, so you have this false sense of security. It's on the backlog. It's never gonna get done, but... that's not transparent that it's never going to get done because it's on the backlog. Yeah, mean, part of that I put on the product owner a little bit, but that could also be that the organization demands it. Like your example with it having different backlogs across different geographies, does it serve a purpose? Well, maybe the purpose is to make someone feel better. That, hey, my thing's number one on our list, but... Barnaby Golden (22:39) Yeah. Brian Milner (22:43) That doesn't mean it's number one, that's the next thing that's going get done. It's theater. Barnaby Golden (22:47) And it was done exactly for that reason. I mean, it was done because they didn't want to alienate the heads of the individual countries. So they wanted to make them feel like they were going to get something even though they weren't going to get it. Which is really frustrating. Brian Milner (22:59) I've seen that as well with the multiple product owners. When there's a team that has multiple product owners, a lot of times that's a theater kind of thing as well, because there's a, I don't know if there's a fear that someone's gonna feel undervalued if they're not called the product owner. But it just seems like, yeah, we want all these voices to be involved with it, which again, maybe it's a misunderstanding of the product owner role. That's okay, you can have multiple voices involved, but you gotta define who's the decision maker. And if a team doesn't know that, that's gonna cause a whole host of problems. Barnaby Golden (23:34) Absolutely. I mean, I've been in scenarios where you would have multiple product owners. The team has been instructed by a product owner to go in a direction and then midway through a sprint, the other product owner will come along and say, yeah, that's not really what I had in mind for this sprint. Can you please switch onto this other thing? And as a, you know, I was a scrum master at the time and what I ended up doing in my sprint report was I would say, and the team lost 20 to 30 % of their capacity in switching. between what one product owner wanted and what the other product owner wanted. And that at least got a reaction because people said, well, OK, maybe that's not a good thing if we're losing output from the team. But it's a failure of the organization to make value judgments and make genuine decisions. Instead, it becomes political decisions. Brian Milner (24:19) Yeah. Well, I'll give you my trick for when I've encountered it as a consultant a couple of times, I usually just ask one question and it'll clear it up. I'll just go to them and whoever the leader is that's insisting that there's multiple product owners on the team, I'll just go and say, all right, what happens when, let's say it's two, what happens when those two people disagree? And usually the immediate thing I hear back is, oh, no, no, no, they get along. They usually understand. Barnaby Golden (24:45) You Brian Milner (24:47) And I always just counteract it really quickly and say, yeah, but what happens when they don't? What happens when the day comes when one of the product owners wants something that's number one and the other one wants an entirely different thing as the number one priority, who makes the call? And usually they'll point to one of them and say, push comes to shove that one. right. I mean, at that point, I just say, well, you just told me that's your product owner, right? Barnaby Golden (25:08) got a little bit more authority so they make the decision here. Brian Milner (25:15) That's the product on the other person's a stakeholder, which is fine. There's nothing devaluing about someone who's a stakeholder. They can work all day every day with that product owner. Barnaby Golden (25:24) Yeah, absolutely. I think that people feel if they're not in the product owner role, then they will just be another stakeholder and maybe they won't have as loud a voice. But what's so frustrating about the situation is when you see it done well, when you see it done effectively with a really good empowered product owner, a very motivated team, it's such a powerful thing. And I mean, it's why I stayed in Agile for so long is because I know how good it can be and It's very frustrating and I guess I have sympathy for organizations because maybe if they've never seen it done well, it's difficult for them to understand how just how effective it is. Brian Milner (26:00) Yeah, I agree. Well, this has been a great discussion. I really like this topic. It's great to focus on product owners a little bit. And hopefully, maybe there is a leader out there or somebody listening who heard some of these things and thought, you know what? Maybe it is time to give our product owner a little more power. We talk about testing things all the time, inspecting and adapting as we go. Well, leaders, try that. Barnaby Golden (26:25) Yeah, maybe just try it as an experiment. You know, if you're concerned, give it a go. Brian Milner (26:27) Yeah. Yeah. Give it a shot and see what happens. You may like it, and you may decide this is the best way to go. So yeah, I think that's a great suggestion. Well, Barnaby, this has been great. I really appreciate you making time for this. thanks for not only being on the show, but for the contributions you made in the Agile Mentors community as well. Barnaby Golden (26:47) Well thanks a lot Brian, I really enjoyed that, it was a great conversation.

What Seinfeld Taught Me about Iterative and Incremental - Mike CohnAgile is both an iterative and incremental process. I've taught this in classes for 25 years. Yet I've never felt like I had the right way to explain how they both differ and relate.Until now.I recently watched the documentary “Comedian,” about Jerry Seinfeld deciding to return to standup comedy after ending his long-running hit television series.The film shows Seinfeld developing a completely new act. He couldn't rely on jokes from his standup routines from a decade earlier.He begins by performing for just a few minutes at small comedy clubs. After each performance he refines the wording, sequence, and pacing of his jokes. He's iterating over each joke.As he finds material that works, he adds time to his show. His performance goes from five minutes to ten. He is incrementally building his show. He continues adding increments (new jokes) until he achieves his goal of more than an hour of new material.Refining each joke is iterating. Adding jokes bit by bit until he has a full show is incremental.This example also shows why iterating and incremental aren't very good on their own. Imagine a comedian who only iterates over existing material but never adds new material. Or one who keeps adding new jokes but never iterates to ensure each is funny.Another thing the “Comedian” movie teaches is the value of experimenting. When Seinfeld (and another comedian profiled in the film) perform, their shows contain a mix of material they know will get laughs and some new jokes they're trying out.Experimenting is equally important in product development. Teams can experiment with their process or the product—by delivering small, partial features to confirm their value before going all-in.I knew agile teams need to be iterative and incremental, but this documentary taught me comedians need to also if they want to succeed at comedy,How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Bring Focus to Your Refinement Meetings - Mike CohnYour team is spending too much time in product backlog refinement.How can I make such a bold claim since I didn't participate in your most recent refinement meeting? I can make it because the vast majority of teams spend too much time refining their product backlogs.So I'm playing the odds, and betting your team is among them. Teams spend too long in refinement because they misunderstand the purpose of refinement, so let's start there. As a reminder:The purpose of backlog refinement is to ensure the highest priority items are small and sufficiently understood that they can most likely be completed within a single iteration.This means that during a refinement meeting the team does not need to get answers to every conceivable question about each backlog item. Some questions can be answered during the iteration without quashing the feasibility of finishing the backlog item in the iteration.For example, suppose a team wants to know how long a failed transaction should be retried. Perhaps 30 seconds? A minute? Two? The product owner says she's not sure but she'll decide within a couple of days.Even if the team doesn't get that answer until after the iteration has begun, that's fine.The team should not need to have all questions answered or all open issues resolved before an item is brought into an iteration. In this example, whatever answer the product owner provides about the retry duration will not affect the two concerns of backlog refinement: Is the item small enough to be brought into an iteration?Is it sufficiently understood to be completed within an iteration?This means that the amount of time spent retrying failed transactions should not be discussed during refinement. (Actually it could warrant just the briefest discussion to confirm that the retry period is minutes—not months, because *that* difference could matter.)From just this example we can see that some questions do not need to be discussed during refinement. Sure, the team will eventually need to know how long the product owner wants to retry transactions. But team members don't need to know that during refinement. And they don't even necessarily need to know it before starting work on the item.Conversations between team members and their product owner during refinement should be focused on confirming an item is small and well understood. Discussions beyond that are often very fun, but they're best had either during the iteration itself or possibly the sprint planning meeting.Keeping off-topic discussions out of your refinement meetings will shorten those meetings with no adverse effect on meeting your iteration goals, which will help you succeed,The Main Reason Refinement Bogs Down Focus on the Two Concerns of Backlog Refinement How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Do Your User Stories End in a Coffee Break? - Mike CohnEver write a user story that the team never finishes?That's a sign you're dealing with an open story—one that doesn't deliver a clear, finished result to the user.Let's fix that. A closed user story is one where the user completes a meaningful goal.Think: “Ah, I finished reviewing resumes. Time for a coffee break.”Contrast that with this story:“As a recruiter, I can manage the job ads I've placed.”That's not closed. Why?Because “manage” never ends. You don't manage something and then say, “Great! That's done forever.”For Here are some red flag words to watch out for: managemaintainadministerconfiguremonitorAs a recruiter, I can review resumes so I can pass good candidates to the hiring manager.I can change the expiration date of an ad to keep it visible—or close it when we're done.I can delete unqualified applications so the team doesn't waste time.I can update ad descriptions to attract better candidates. Each one finishes with something tangible.Closed Stories Let Users Take a Coffee BreakRed Flag Words to WatchThese words signal that your story might be too broad or too vague. How to Close Open StoriesBreak “manage job ads” into stories with meaningful outcomes: Each one earns that coffee break. Why Closed Stories MatterClosed stories avoid misunderstandings. A vague story like “manage ads” might mean running reports to the product owner; the same story might mean UI tweaks to the team. That gap in understanding leads to rework.And yes—open stories have a place as epics early in a project. But when it's time to build, break them down into stories with clear outcomes.That's how teams build clarity—and succeed with agile.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/