Podcast appearances and mentions of Mike Cohn

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/

Join Brian and Mike Cohn as they unpack the five essential pillars that take Agile from “just the motions” to meaningful, measurable impact. Plus, get a behind-the-scenes look at their revamped course built for real team transformation. Overview In this episode of the Agile Mentors Podcast, Brian is joined by longtime collaborator and Agile thought leader Mike Cohn for a deep dive into what really makes Agile stick. They explore the five foundational pillars—mindset, practices, roles, teamwork, and support beyond the team—and share stories of what happens when teams get them wrong (like obsessing over story point math or demoing a copyright update in a sprint review). Along the way, they introduce the newly available Working on a Scrum Team public course and explain why it’s designed for entire teams, not just isolated roles. Whether you're new to Agile or knee-deep in transformation, this episode will help you rethink how to build an Agile approach that actually works. References and resources mentioned in the show: Mike Cohn #80: From Struggling to Success: Reviving Agile Teams with Mike Cohn Scrum Team Roles and Responsibilities Working on a Scrum Team Course Mountain Goat Software Certified Scrum and Agile Training Schedule 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. 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. Auto-generated Transcript: Brian Milner (00:00) Welcome in, Agile Mentors. We're back for another episode of the Agile Mentors podcast. Thanks for joining us. I'm with you, as always, Brian Milner. And today, I have the one and only Mike Cohn back with us. Welcome in, Mike. Mike (00:12) Thanks, Brian. Good to be here. Brian Milner (00:14) Always happy to have Mike on the show and really appreciate Mike making time to come on. Wanted to have Mike on because there's some things Mike's been talking about recently that are really interesting and people have been asking a little bit about this and I thought maybe it'd be just a good opportunity to talk through some of the stuff that Mike's been writing about. I know you spent, Mike, a lot of time helping teams to not just do Agile but to really get solid results from it. to see impact from it. And I know the topic you've been talking about recently is sort of these five pillars of supporting real agile improvements, the mindset, practices, roles, teamwork, and support beyond the team. So I thought maybe we could just dig in and drive through those and maybe learn a little bit about those as we go. Obviously also to talk a little bit about the exciting new course that's being launched here, the working on a Scrum team course, because I know that was originally just for private classes, right? And now it's being open to the public. Mike (01:23) Yeah, we've done working on a Scrum team as a private class for probably 20 plus years. It's been kind of our main offering to private clients. But we're hearing from a lot of people that they have one team and they can't really get a private class approved with the budget and such. So what we're doing is going ahead and making that course available as a public course. So two people from your company, five people from another company all in the same class the way we've done our certified courses for decades. And so we're going to start offering this as a public course. And the exciting thing there is that it's really meant to be a team-based class, where things like Scrum Master training, great class, but it's really meant for the Scrum Master, right? And working on a Scrum team is really designed, and you and I helped you and I design this course together, but it's designed to be something that is a whole team training, right? So good for anybody on a team. Brian Milner (02:16) Yeah, yeah, it's been really great teaching those in the private classes and I'm excited to think about the public being able to come in and take that now. Let's talk a little bit about these pillars and, I think people are gonna be really intrigued by the concept here. The first one is mindset, I think, and just wanna start there and say, what does it actually mean to... think Agile and what is the found, why is that kind of the foundation for successful transformations? Mike (02:43) Remember the kind of the early days of agile and there was a lot of conversation about could you be agile without understanding the principles, right? If you just did the practices, were you agile? Other people were saying, no, you have to start with the principles, right? And so do you start with principles? Do you start with practices? And I remember these early debates and they often devolved into a discussion of the karate kid movie, right? Remember that one, right? And, you know, can you just wax on? Brian Milner (03:12) Ha Mike (03:12) for long enough, just do the practices. And then all of a sudden, your karate instructor or your agile coach is, OK, you're agile. And it's like, wait, all I know how to do is wax a car, right? And so there were these discussions about practices versus principles. And I was kind of always on the side where you better understand the principles to do this. Just knowing the practices, waxing on all day, is kind of just going through the motions. And so you have to understand the principles. And the idea that I wanted was that if a team truly understood all of the principles underneath Agile, I don't just mean just the manifesto, but all the principles that are there from Lean, from Kanban, from everything, that if you really understood those, you'd kind of invent the practices, right? You do those and you go eventually to go, hey, we should probably meet every day. Or hey, if we tested first, that might be a really good thing. Brian Milner (03:57) Yeah. Mike (04:05) So you'd invent the practices if you really had that type of agile mindset. And so for me, when we're working with organizations to get them truly agile, and I don't mean like more agile than less agile, but agile in a way that's going to stick, you got to change mindsets, right? You've got to do more than just the wax on. So people have to get the mindset. Brian Milner (04:27) Yeah, I love that. I know that I've experienced some things in the course of working with people that's it's sort of like you, if you're not on the same page with the principles, then you start to talk through the practices and you run up against a problem. And really what you find out the core of it was, well, we weren't aligned on really the principle behind this. So why would I want the practices then, right? ⁓ Mike (04:49) Yeah. Well, that's where you also end up then with a lot of team debates about things, right? Because you're arguing about the practice. if you'll say you and I are arguing about the benefit of some practice, if we agree on the principle, we might just have different views on it. But deep down, we'll probably agree on some practice, or we might find an alternative one. But if you don't agree on the principles, you end up with a lot more of these kind of annoying. mean, team debates are great. I mean, I love. Brian Milner (04:54) Yeah. Mike (05:12) you know, having a team debate, arguing stuff like that, but not about pointless things, right? And not without some sort of foundation. They just kind of get in the way. It's just frustrating for everybody. Brian Milner (05:21) Yeah. Well, I'm kind of curious, what kind of signs or signals do you think teams should look out for to kind of clue in and let them know that what might actually be going on here is more of a mindset issue? Mike (05:36) think sometimes it's when you hear the appeal to authority, right? Somebody says, you know, well, we got to do it this way because the scrum guide says, right? Or the one that annoys me is we have to do it this way because Mike Cohn says, ⁓ you know, that was like, no, I, somewhere else also said, think, right? Don't just, you know, don't just, you know, blindly do story points or something. Cause I say they're a good thing. I want you to think too. Brian Milner (05:50) You You Mike (06:01) And so I think that kind of appeal to authority when teams are debating things. It's where we also see teams who think they're agile because they do a set of practices. We use a particular agile tool, so we must be agile. We do daily meetings. We must be agile. And those are not the things that make you agile. Those are artifacts of being agile. If you're agile, you're going to meet a lot. You're not going meet a lot, but you're going to talk a lot. Um, and so those are the artifacts of behaving in an agile way. And so I want to understand why we're doing those things. So I look for those kind of appeals to authority. Um, you know, emphasis on that type of stuff in an argument talking about how this is the right way saying there's only one right way to do something. Brian Milner (06:49) Yeah, yeah, that's great. How does working on the Scrum team deal with this? How does that address it? Mike (06:55) Well, one of the things we do, it was actually one of my favorite exercises. We do this exercise at the start of the class where we ask people to kind of map out how the organization talks about certain adsel principles and then how does the organization behave. And so for example, if a company says, people are our greatest asset, and then they treat people like dirt, we've got this kind of problem between what we say and what we do. And so I like to kind of map this out. And so we do this with the principles in the Agile Manifesto. And once we map those out and we start to see things that we say we value, but we don't behave that way, really helps us understand if we've really embraced that mindset. Or are we just doing things because an Agile coach told us to, or a boss told us to, or we did it that way in our prior company. Those are all bad reasons to do something. Brian Milner (07:48) Y eah. So this is great. So I agree. The mindset's really foundational. And there is this symbiotic relationship between mindset and practices, which came first and which comes first, as we talked about. I know a lot of teams get stuck doing Agile, though, in really only name only. So when we talk about practices, what makes the difference between going through the motions? Mike (08:00) Mm-hmm. Brian Milner (08:11) and actually doing things that work. Mike (08:13) Well, practices is kind of our second pillar, right? You have to have the mindset, right? But you also have to have the practices that come from having that mindset. so, again, I try to think of that team on a desert island, right? And they're isolated from the world. They've never talked to anybody, but they have an agile mindset. What practices are they going to invent, right? And I think those are kind of the core practices. We see a lot of problems with as an example, teams that misunderstand sprint planning. And I know when I first started teaching about sprint planning, I'd have a slide up there to have a picture of a sprint backlog. And the sprint backlog listed tasks like code this, design this, test this. And then there were estimates next to code this. It's going to take four hours testing. It's going to take three. And so we were able see all these numbers and think the point of a sprint planning was these numbers. And Even in the early days of this, I was always saying, no, it's not about those numbers. It's about deciding what product backlog items you can pick. if taking a, I don't even want to call it an estimate, but taking a wild guess about, it probably can take four hours to code. If that helps you decide how many backlog items you can commit to, great, put those numbers up there. But it was never about the numbers. And it's one of the most common problems that I see with teams in sprint planning is they get obsessed with How many hours did we bring in? How many points did we bring in? And I remember one team I worked with where we did sprint planning. Having those estimates were helpful for them on their sprint back. They were helping. And we finished the meeting. And we're using Google Sheets in a meeting to do this. We've got a row with the estimates in there. And as we start to wind down the meeting, I deleted that column that they'd spent so much time talking about. They're all kind of pissed off at me. Why'd you delete that? We spent all this time talking about it. I said, because we got the benefit, right? You got the benefit of those numbers. The benefit isn't a week from now remembering that you said five hours, because it's going to take what it takes. The benefit was the discussion that it led to of can we take more or are we already full? So I see teams get obsessed with that. This is one example, but that's one of the problems with sprint planning as a practice. Brian Milner (10:25) Yeah. Yeah. I think you're absolutely right. And that's one of the things I know I've talked about with people going through the course is sort of understanding the purpose behind the things. Just going back to, know, harkening back to what you said about, don't just do it because someone told you, you know, understand why the purpose behind it. And, know, otherwise we, I'm sure we've all had that experience before where someone just tells you to do something and says, you know, why? Cause I told you so, you know, that, that doesn't, that's not very convincing. Mike (10:52) Thanks, Mom. Brian Milner (10:53) Right, right, thanks mom. Yeah, not very convincing, but it's much more convincing when they can tell you, well, no, you do this because this is what we're trying to do. And I think you're right, that makes all the difference there. ⁓ Mike (11:05) It just, don't know anybody that responds well to being told what to do, right? My instant reaction is no, right? mean, you it could be, you know, a really, you it could be a really good thing. Eat more vegetables, you spend more time outside. No, right? Don't tell me what to do. So. Brian Milner (11:09) Right. Right. Yeah. It's almost like our default response is no until you convince me. Are there other common practices? We talked about sprint planning. Are there other kind of practices you see teams struggle with? Mike (11:28) Yeah, yeah, for a lot of people. think a huge one is product backlog refinement. I don't know what a better word would be than refinement. refinement is about making the backlog better. It's not about making it perfect. And I see teams that get stuck on backlog refinement and feel like they have to resolve every open issue, that everything has to be tiny and answered and buttoned up before we can start a sprint. And that's not the case. For me, the goal in refinement is to make sure things are small enough and sufficiently well understood. I don't want to bring in a backlog that's bigger than my velocity. If our velocity is 25, I don't want bring in a 50-point story. how about the problems of a 50-point story anyway? But I don't want to bring in some massive epic like that into a sprint. And so refinement is about making it small, making sure it's sufficiently well understood. Sufficiently well understood, not perfectly. And so Brian Milner (12:18) Yeah. Mike (12:28) The problem is these teams, and I know you've seen this, but teams who get in there, want to resolve every open issue. It's like, no, we can resolve that during the sprint. If we think about the goal and planning to make sure we know what to bring into the sprint, not too much, not too little, we're fine just enough that you're at that point. Is the button blue or red? Who cares? If it's a log in story, we're going to lock people out after some number of failed attempts. Who cares how many? Figure that out during the sprint. If it's five or three or eight, who cares? Figure that out later. So I think refinements won. Another big one would be reviews, ⁓ where sometimes teams demo too much in a sprint review. And they feel like they have to justify their existence, show everything you did during the sprint. And the most egregious example of that was this was a handful of years ago. But I literally remember a team showing Brian Milner (12:58) Yeah. Yeah. Mike (13:18) how they had updated the copyright notice on the footer of the web page, know, copyright, you know, whatever year our company, right? And it's like, my God, you didn't need to show that to stakeholders, right? We all either know there's a copyright notice on the bottom of the web page or we've seen one before. I don't need you to bring it up and scroll down to it. Now only took 15 seconds of the meeting, but that was 15 seconds of people's lives. They were never going to get back. you know, show stuff that you need feedback on, right? If you'd... Brian Milner (13:41) Right. Mike (13:45) You fixed a bug and you fixed it only way it could be fixed. Mention it perhaps, but you don't need to show it, right? Brian Milner (13:51) Yeah, yeah, know teams I've been on often it's just it's suffice it to have a list sometimes and just say here's a list of things if you want to know more about these come talk to us but we're move on to the stuff you care about. Mike (14:02) Yeah, I always have like a will show, will not show list. you know, I often, if I'm writing the meetup present, that'll put that up on Zoom or, you know, show it on a screen if we're in person. And often somebody wants to see something that's on the will not show list. Or they just want me to describe what bug was that again? What was that? You know, and I'll explain it really quickly. But if nobody wants to see it, don't bother showing it. So. Brian Milner (14:26) Yeah, I know we talk about these scrum practices quite a bit in the working on the scrum team class, but if someone signed up to take this class, what can they expect to hear or what can they expect to learn about these practices in the course? Mike (14:39) Well, I think one of the things that you and I did together in creating the newest version of the course was to look at what do you actually need to practice doing, and it's feasible to practice doing in a classroom setting, versus what should you just kind of talk through. And not everything needs to be practiced to get the hang of it, right? Everybody in the world has taken something big and split it up into smaller things before, right? I need to make. spaghetti dinner tonight. What do need to buy? Right? OK. Well, that's that's that's test decomposition by noodles, by sauce, by tomatoes. Let's make it from scratch. Right. By some garlic. Right. So everybody in the world has done decomposition. We've broken a big thing into small things. And I remember, you know, iterating over I'm still on sprint planning, I guess. But I remember iterating over exercises in sprint planning and in courses over the decades by now. And I would have one where you're planning a party for your kid, break it down into tasks. It's like, nobody learns anything from this. And so that's one where I'd rather say, OK, this problem occurs in sprint planning. How could you solve it? Other things like, let's say, splitting user stories or splitting job stories, that's a skill worth practicing together, getting feedback on. And so those type of things we try to practice in the course. other things we just talk about. mean, I'm curious on your thoughts on that. What do you think about some things being worth practicing, some things worth being better talked about? Brian Milner (16:01) Yeah, I agree. I agree fully. it's, it's, you know, there's some things, it's kind of like what you said before, there's some things that's not worth spending the time on, and it's better to just have a discussion and move on. Mike (16:13) Yeah. Yeah. I guess that's one of the things we always talked about. We always talked about return on investment of the exercise. What's the return on the exercise? And if you're going to have a one hour exercise, cool. One hour exercise. But it better have a pretty healthy return because that's a lot of time in class. And so what's the return on exercise? Is this worth a practice? Is it worth just a discussion? And if we can discuss two hard problems and give people advice on two common problems, they're probably going to face. Brian Milner (16:21) Yeah. Mike (16:41) Might be better than spending 20 minutes practicing something that they've probably done before. Brian Milner (16:45) Yeah, I completely agree. Let's move to the third pillar then, because I know this is a big one, just thinking and talking about the roles. And just as far as communication issues are concerned, even outside of Scrum, I know that's part of the big problem with teams and organizations just not being clearly defined about who does what and who's responsible for each thing. So those misunderstandings are really common failure points. ⁓ Mike (17:09) Mm-hmm. Brian Milner (17:10) How do you see teams getting that wrong and how's that derailing a Scrum team? Mike (17:15) Well, think we see it all the time on Scrum teams between Scrum Master and Product Owner and even the development team, right? Who does what? I was responding to some comments on LinkedIn this morning on some post I'd made last week and somebody had some comments. And it had to do with whether the Scrum Master or Product Owner does something. And it was interesting because in the comments on that post, I... I don't remember which one it was, but I shared a certain perspective. I feel pretty strongly that I have it right. I mean, I this is how we do it. But there were other people saying the opposite, right? And so, you know, these are people that are probably fairly experienced with Scrum, if they're following me on LinkedIn and feel comfortable commenting on a post, probably feel comfortable with it. And so there's a lot of confusion about what role does what thing. And I don't think this is something where the Scrum guy is going to have the answers for you. I think it's, I mean, you can look at the Scrum guy, oh, this. Here's my starting point answer, but we always want to play to people's strengths, right? And if you've got a scrum master who's got a lot of skill in one area, maybe they shift a little work from the PO to themselves, right? With the PO's permission, right? And the opposite, right? Between maybe PO and team. So it's fine to have default starting positions on who does what, but you always want to play to people's strengths. So I think PO scrum master, I think we see it with project managers and scrum masters, roll confusion on those type of roles as well. Brian Milner (18:38) Yeah, completely agree. A lot of those roles that are not named Scrum team roles and how they interact with the team, that's often a source of confusion as well. What are maybe some signs or symptoms that teams might be having confusion or problems in this area that maybe they don't even recognize or realize they're having an issue with roles? Mike (18:59) Any sort of conflicts, right? You know, you and I arguing over which one of us should do something. The other one would be kind of the opposite, which would be like a dropped ball. I was watching some YouTube video. I love baseball. I was watching some YouTube video the other day of like missed catches or something like that. And some team hit a baseball way up in the air and it was landing near three players, right? Three players are all looking at it. Brian Milner (19:12) You Mike (19:23) One guy waves the other two off, he's going to catch the ball and he must have been blinded by the sun because he's like six feet from the ball when it lands on the ground, right? And, you know, if we have a responsibility to catch the ball, run this meeting, right, right the backlog, the kids dropped, right? And so I think either arguing over who does something, two of us trying to do the same thing or neither of us doing it. I don't mean trying to get out of the work, right? All three players have been happy to catch the ball, but I think you've got it. You think I've got it, right? Those type of things are pretty good signs. think getting clarity around these roles can really optimize how a team works. And I think a really key thing here is that it changes over time. So I'll go back to my example of maybe the Scrubmaster has some skills that can help the product owner early on. Because maybe the product owner is new to the company. The product owner doesn't know the product as well. So they might rely on the Scrubmaster for guidance on things. Well, a year from now, we might shift responsibilities a little bit because now the PO is the expert on all things related to the product. So it's not like we want to establish clarity on roles one time and leave it forever. It's going to change. We get a new tester on the team, things might change. Product owner moves. It's going to change again. So we need to realize these responsibilities are dynamic. Brian Milner (20:39) Yeah, that's a great point. Your point about baseball just made me think about how, when you watch any youth sport in the world, when you go watch your kids play a sport, what's the one thing you always hear people scream from the sideline? Talk to each other. Call the ball. Well, that too. That too. Ump your blind. Those kinds of things. Well, let's talk a little bit about Mike (20:52) I thought you were going say, put my kid in. Brian Milner (21:00) I know this course addresses the roles and how would you say this course really helps address that issue of role confusion? Mike (21:07) think a big part of it is that we designed it to be for everybody on the team, right? Suppose you send a scrum master to a class, and it's a great class. Scrum master is going to back to the certain set of impressions about their role. Product owner goes to an equally good class about the product. They might have different impressions. Even if they took the course from the same instructor, they're hearing it a little differently. They're hearing it through their filters, right? And so when they're in a course together, there's more opportunities to clarify their understanding about those things, especially in the classes designed as we did with this one to bring out some of those differences. So I think the course helps with that. we've also designed it to mention the rules we haven't talked about, like managers and things like that. Brian Milner (21:53) Yeah, yeah, I think those are so important. And there's a lot of great discussions that come out when we have those topics. ⁓ Let's talk about the fourth pillar then, teamwork, because this, I think, builds really well on what we just talked about. And the idea that there's actually, Scrum is a team sport. ⁓ So beyond just normal human personality conflict type issues, what do you see that gets in the way of teams actually Mike (21:58) Mm-hmm. Mm-hmm. Brian Milner (22:18) working as a team. Mike (22:19) think ego is probably one, right? I can do everything better, just leave me alone. There's an old book that says basically, beware of a lone developer in a room, right? You know, it was referring to the developer who wants to close their door and say, I'll it done in a month, trust me, right? And one of the companies I worked with, and this one's going back like 15 years ago, but it was a really good story. Brian Milner (22:36) Yeah. Mike (22:43) is they would literally grab one unit of work. Each person on the team would grab a unit of work and take anywhere from three to 12 months to do the thing. So they were big things, but the person would do everything on it. They'd coded, tested everything. And the organization was putting out very little because of this. When they moved to Scrum in the first year, by their estimate, they said they delivered 540 % more work. over five times the amount of new features delivered. And that was through the collaboration, through the short iterations, those type of things. But it was about getting people to collaborate more. So I think there's huge opportunities to do that. One of the problems I see is when we don't overlap work. If we think about that organization I just described, you grab your thing, you're done in six months. I grab mine, I'm done in seven months. If we'd work together on those things, what's not make us any faster? No faster. But you and I could have worked on your one thing and been done in three months. OK, we're delivering value in three months, right? And so one of the things I look for a lot is how much teams are overlapping work, right? And if we're not overlapping work, there's huge opportunities to improve at that. I'll a little example of this. One of my favorite restaurants is, I don't know, barely call it a restaurant. It's a fast food deli. It's called Jimmy John's. Have you been to Jimmy John's, Yeah. Yeah, there's one near my house where I can go there and the wine will be out the door. Right. And you know, normally you see a wine out the door and it's like, crap, I'm going somewhere else. Right. These guys are so fast. They're so fast. When I get to the front, I place my order. I play this little game of can I fill up my cup? You know, I get an iced tea and they give me an empty cup and can I go fill up ice and put the tea in before they hand me my sandwich? And it's about 50-50. Right. It doesn't take long to fill up your iced tea. But the way they do that is the overlap work. As soon as I order my Italian club sandwich, somebody's already got the bread open, somebody's got a slab of meat they're ready to drop on there, somebody else has their hands over the vegetables and they're dropping the vegetables on there, and then a fourth person wraps it up. And so like four or five people touch my sandwich. Hopefully their hands are clean, but four or five people touch my sandwich as opposed to like most delis where I go and it's like you watch one person plod along making the sandwich, right? Overlap work is huge. Brian Milner (25:07) Yeah. Yeah, this episode sponsored by, no, just kidding. Use code Mike Cohn when you go to, no, just kidding. Yeah, I agree. And yeah, yeah, I'm familiar with Jimmy John's. Probably too familiar. ⁓ Yes, yeah, no, that's, I think that's part of their shtick is that they're, you know, they're known for being fast. So yeah. Mike (25:10) You Is yours just as fast? Yeah. Yeah. They call it Freaky Fast. They actually have a competition. I've seen YouTube videos of this where they get like the best teams at various restaurants race, right? And so they have like the Jimmy John sandwich making Olympics or something, but it's a skill. Brian Milner (25:36) wow, wow, yeah. You should pair that up with the hot dog eating challenge in some way and see if we could have a team sport going there. ⁓ Mike (25:48) Well, that's a good point because think about the hot dog eating. That's one guy, right? That's Joey Chesnett shoving hot dogs down. The Jimmy Johns is a team. They get the best crew at a restaurant and it's a team, right? How fast can the team go? Not how fast can one guy make a sandwich, right? Brian Milner (25:51) Yeah. Yeah, yeah. That's awesome. So what are some tips? What are some ways that you can really unite a team, especially those new teams? Because that's the fascination point for me is, how do you take this group of humans that really don't know each other and haven't worked together in the past and unite them together and have them gel as a team? How do you do that? Mike (26:21) I'll give you a couple. One, I think having really crisp sprint goals helps. So we all know exactly what we're trying to get done in the sprint. We don't lose sight of that because sometimes in the middle of a sprint, you lose sight of it. And you get myopic and you just focus on a list of tasks. And I'm going to say that it's probably similar to the team doing sprint planning and just getting them assessed with the numbers. It's not about the numbers. It's not about the tasks. It's about the backlog items that lead to some goal. So crisp sprint goals help. That's a hard phrase. Crisp Sprinkles helps. The other one I'd say is having a shared vision about where you're headed over a little bit longer term. Probably the biggest change to the Scrum Guide ever that I've liked is the inclusion of a product goal. And that was something I'd been talking about forever. mean, literally since I started doing Scrum was that sprinkles are great, but they're pretty short, right? You want to have something bigger. Brian Milner (26:52) It is. Mike (27:14) And so I like having product goals that are a few months out there. And one of the things I like doing for product goals is have teams do something like write a press release that describes their goal or create a vision in some way, write a review that you want to see come out on the App Store, Play Store, and a magazine. And one of my clients made software and they were reviewed by a major magazine and they were given an editor's choice runner up award. And they actually estimated that being runners up for that was probably worth about $10 million. First place, first time was worth about $10 million a year to them. And so they decided to get serious about this and they wrote a review. Their scrum master, she was actually combo scrum master product owner, Erin. She had the team write a review and she said, let's go earn this review. And I literally remember the email I got from her three months later. It was because it was Halloween night. I just like, you know, brought in the candy from outdoors. We're done trick or treating. And I checked my email. I a three word email from her from Erin. said we did it. And the magazine had let her know, hey, we're reviewing you. be out on, you know, like Tuesday's edition. And the review had quotes in there that were from their vision review, right? The things that they had wanted to achieve. Brian Milner (28:22) Ha ha. Mike (28:35) And that team had just really jelled around that and just became so much more productive and collaborated so much better because of that shared vision. Brian Milner (28:43) Yeah, that's amazing. getting back to the course then, I know in the course we're trying to kind of some of those collaboration muscles. What are some of the ways that the course helps to build that? Mike (28:56) think one of the key things that we're doing, and I'm excited about this, is that we're, you know, we of course use Zoom breakout rooms, right? You you go talk about this, we'll see you in eight minutes or something like that. And for this course, we're doing something where a group of three or more, when they register, can have a private breakout room. And this to me is exciting because people get the benefit of having a private breakout room. They can have sensitive discussions if they want. They can talk very specifically about. you know, what do we do about our jerk product owner? mean, whatever it is, right? You know, they can talk about their specific issues, yet have the context of a broader class. Because I think in one of the benefits of any public class is hearing how other teams are doing things. And sometimes that's because you get a good advice, you know, how did you solve that problem? We have that problem. Other times, it's just feeling that you're not alone in the world. they've got that problem too, right? And they don't have any solution for me, but I know I'm not alone in the world with this. And so I like these private breakout rooms for three or more. I think it's a novel thing we're doing with this class. And it's with the intent of combining the best of both worlds of private and public training for this. I'd the other thing is probably consistency, having everybody on the team hear the same message, having those discussions with an experienced instructor like you or me in the room to provide guidance when they have questions. know, go back to the role clarity, right? You know, they can talk about it and they're there. Then they're back in the main room with you or me and we can kind of answer questions. So I think that consistency will be huge as well. Brian Milner (30:25) Yeah, yeah, I love that idea of the private private breakout rooms that that's that's gonna be huge for a lot of people I know. ⁓ Mike (30:31) I'm excited to try it with this. This will be the first classes we do that for. I'm excited about it. Brian Milner (30:36) Yeah, yeah. Well, let's bring it home then and talk about the fifth pillar because the fifth pillar is really interesting as well. It talks about support beyond the team and teams can only do so much. Every team struggles when they're not supported well. And there's lots of studies that show leadership support is one of the biggest hurdles or obstacles to the adoption. Mike (30:46) Mm-hmm. Brian Milner (30:59) What does that support look like from outside the team and how can a team influence that? Mike (31:06) Yeah, if you're trying to be agile and your HR group has quarterly reviews of personnel that are all based on individual performance and has nothing to do about teamwork in there, it's going to be hard to focus on collaboration. So we have to kind of fix these issues. I think what we have to do here is to have team members educate those outside the organization. And we have information that we share about, you here's how to talk to a boss that's maybe mandating deadlines, things like that. And so we try to coach people through having some of those challenging conversations. And one of things I want teams to do is kind of become an example of what good agile looks like. And if you have a team that's excelling with agile and they're doing it from a kind of principles first, that mindset first approach. You're going to see other groups look at that and let's say the marketing group. They're going to look at that go, hey, that's an interesting way to work. I wonder how we could do that, right? And it's going look different for a marketing group than a tech team. the mindset is going to be the same. Principles will still be the same. And so when we get teams to do really well with this, other parts of the organization start to get interested. And then they stop being as much in our way. Brian Milner (32:20) Yeah. I know one of the most important aspects here and that we talk about is, is that you don't need to, to wait, right? If you're the team level, you don't have to just sit around and wait for the organization to make changes. you, you have opportunities to make changes as well. So how does that happen? How's the team change, you know, bring about those changes that, improve the agile process, the results. Mike (32:42) I think that's by being the example so that people see it. I think it's by having those conversations. You know, one of the things that we'll get is, you know, it's so common is the product owner that wants to change their mind all the time. I was reading something, I guess this is in our Agile mentors community, I think is where it was, but it was about the, you know, the product owner who said his favorite thing about Agile is that he can reprioritize every week. ⁓ And it's like, you can, you know. Brian Milner (33:05) Hmm. Yeah Mike (33:10) I'm not sure it's good. And I think about that, a team gets momentum, right? And you're working on a certain feature. Next sprint, it would be nice to work in that same area of this system, right? Your head's there. Just kind of keep going a little bit. And I've often described this as like, let's say you're working on three backlog items that are in a certain area of this system. Let's make it concrete. Let's say it's the spell checker in Microsoft Office, right? And you do three backlog items related to the spell checker this sprint. Next sprint, maybe your top priority is not more spell checker stuff, but maybe items, I don't know, 25, 26, and 27 on the backlog are still in the spell checker. You know what? It might be better to do those. There are probably two or three sprints away. Let's bring them into this sprint. Just get them done while my head's into spell checking. And so getting product owners or stakeholders to stop doing that, one of the ways that I like to talk about doing that is using an example of ordering a meal at a restaurant. I can order, let's say, the chicken entree. And then as the waiter is taking the orders around the table, I change from chicken, no, bring me the fish. Not a big deal. The waiter is going to cross off chicken and write down fish. If the waiter goes away, brings me back my salad, and I change my mind then, I say, hey, bring me the fish. Might not be a big deal. It's going to be a big deal if I've already taken three bites of the chicken. right? Or if he brings me the chicken. So yeah, we can change our mind, but there's a cost, right? And we want to educate stakeholders about that cost. They don't overdo it. Brian Milner (34:31) Yeah. Yeah. Well, speaking of the leaders and the organization, managers, leaders, do you think this course is appropriate for managers and leaders to attend as well? you feel like they might need to in order to really have this be an impact? Mike (34:55) Yeah, that's a good question. Is it appropriate? Yeah, I think it's appropriate. When we do this privately, we've had plenty of leaders and managers attend. I think it's great. I don't think that's required because they're not on the Scrum team. You said the name of the course is working on a Scrum team. And so they're not on the Scrum team. They benefit by knowing more how their Scrum team works. But I think what we found is that having just a key subset of people who hear the same message work through the training together, and then go back to the organization. That's enough to bring the passion, conviction, and skills that we want. So we don't truly need leaders. They're great. I would never talk a leader out of going, but I wouldn't. If I were a team and I could take the class this month or with my leader next month, I would just get the class done, right? And educate the leader afterwards. Brian Milner (35:41) Yeah. Yeah, yeah, I think that's a good plan. All right, well then we've made our way through the five pillars and for people who have come this far with us and are at this point, if they're listening and they're recognizing some of these problems we've been talking about, what would you recommend to them as next steps here? Mike (35:49) if Well, take a look at our website. If you go to mountaingoatsoftware.com. And then I think there's a courses link on the top. You can go up there and find the link to this course. It's an exciting one that we're doing. I've literally been teaching this, I think the first time I taught a class called Working on a Scrum Team was 2003 or 2004. it's a time tested course. You and I kind of redesigned it a couple of months ago to make it appropriate for public. or little better just in general and more appropriate for public. But it's a time-tested course that's now designed to be available for public settings instead of, you know, have to have 25 people or something. Brian Milner (36:36) Yeah, yeah, that's really exciting. I can't wait to see kind of how people are in, you know, react and interact in the course to some of these concepts and ideas. And we'll, we'll of course link to all these things that we've talked about in our show notes and make it easy for everyone to find the course listing and, and, you know, where the dates and everything that we're going to offer them. So make sure to check that out. Mike, thanks so much for coming on. This has been really enlightening and I appreciate you making time for it. Mike (37:01) Of course, thanks for having me, Brian. Always a pleasure.

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/

Dolly Parton Can Improve Your Teamwork... - Mike CohnWould you like to get a check from Dolly Parton for $500? I would.In an effort to reduce the number of students who dropped out of high school in her home county, she promised all 7th and 8th grade students she would give them each $500 if they graduated from high school.She added a catch: They'd only receive the money if a buddy they chose also graduated.Dolly's Buddy Program reduced high school dropouts from 35% to 6%.She clearly understood the importance of accountability to one another: a student contemplating dropping out may not when they factor in the financial impact on their buddy.I wish Dolly Parton would make a similar offer to teams. The best teams understand that they succeed (or fail) together.No one benefits when the programmers finish coding on the last day of an iteration, and leave testers no time to test.When shared accountability pervades a team, people help each other. Programmers may write more unit tests if they know testers will be challenged. Or they may execute some tests themselves.If testers are concerned that programmers may not finish, they can help by identifying earlier and sharing the edge cases that programmers may overlook.There's always something you can do to help your coworkers. Beyond helping out in a pinch, here are some practices that help a team succeed together: Small backlog items that flow through the process more smoothlySmall, frequent handoffs to reduce waitingClose collaboration to improve communicationOverlapping work to avoid leaving too much testing until the endDaily scrum meetings to encourage accountability to one anotherFostering an attitude that everyone succeeds together may not get you a $500 check from Dolly Parton, but it 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/

Don't Doubt the Power of Fast Feedback - Mike CohnEvery year when summer rolls around, I start dreaming about getting out on the water: sailing, rowing, kayaking, wake surfing, and so on. If it's a water sport, I probably love it.And every time I work with a product that doesn't quite meet my needs, I start thinking about how important it is to get real user feedback early and often.Today, those two thoughts combined. I was sighing over the latest update to a less-than-optimal work management app, and my mind went back to a 1995 America's Cup race. The race between the US and New Zealand is a great illustration of the importance of two vital activities for agile teams: knowing customers and getting fast feedback. To create their boat, Team New Zealand used software that allowed them to simulate the impact of various design changes on the speed of the boat. They evaluated thousands of design decisions. Each day, Team New Zealand ran simulations on a small network located a few feet from the dock. To further evaluate designs, Team New Zealand made two boats. Each day, they would alter one with a design change to be evaluated. The two boats then raced each other to assess the impact of the design change. By contrast, the U.S. Team designed their boat using massive supercomputers located hundreds of miles from the dock. This created significant feedback delays. The team also had only a single boat for testing, which made it harder to assess the impact of changes. Yep. Tiny New Zealand. For the very first time.Why? Because Team New Zealand got close to their customer and used rapid feedback cycles. If you are not cycling ideas past your customers quickly enough to get rapid feedback, consider moving closer to the dock.New Zealand Went Small, Close & OftenThe U.S. Went Big, Far & SeldomGuess who won?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/