The Agile Daily Standup - AgileDad

Wait Wait Don't Tell Me... - Mike Cohn

Apr 10, 2024

Agile expert Mike Cohn discusses the importance of starting work in agile teams without all answers upfront, promoting flexibility. He highlights the negative effects of demanding full acceptance criteria for backlog items. Emphasizes iterative nature of agile development and continuous learning, stressing the significance of balanced information provision.

07:28

Creator website

Episode guests

Mike Cohn

AI Summary

AI Chapters

Episode notes

Podcast summary created with Snipd AI

Quick takeaways

Agile teams benefit from starting work without all details, promoting adaptability and problem-solving abilities.

Demanding exhaustive information upfront hinders agility and mimics a more rigid sequential approach, impeding progress.

Deep dives

Importance of Starting Without All Answers

Agile teams benefit from starting work without having all the details, promoting adaptability and problem-solving abilities. Demanding exhaustive information upfront hinders agility and mimics a more rigid sequential approach, impeding progress. The focus should be on beginning with the available knowledge and adjusting along the way, rather than waiting for perfect clarity before commencing.

Embracing Uncertainty and Flexibility in Agile Work Practices

4min

Navigating Task Completion and Continuous Learning in Agile Development

4min

Wait Wait Don't Tell Me... - Mike Cohn

In the US, National Public Radio runs a popular weekly news quiz show called, “Wait Wait … Don’t Tell Me!” I was listening to the show the other day while driving back from the airport to my home, and it got me thinking (and laughing too. It’s a funny show.)
“Wait wait … don’t tell me,” might be a good mantra for Scrum teams to use with their product owners. Or perhaps better, “Wait wait . . . tell me later.” Agile teams need to be willing to start without having all the answers up front.
Some teams, though, expect the product owner to have every answer figured out before work can begin. This happens with new teams, and more frequently than you might think, also with teams that have been doing Scrum a while.
Teams that refuse to bring a backlog item into the sprint until they have all the details buttoned down are getting in the way of their own ability to be agile.
Most commonly, this shows up as the team demanding the product owner provide full acceptance criteria for each product backlog item before that item can be brought into a sprint.
This is a step back toward a waterfall or sequential approach. It essentially establishes a gate at the start of a sprint. No work is allowed through that gate until all open issues have been resolved.
To overcome this, team members need to become comfortable with uncertainty. And so do the product owner and business stakeholders. You don’t need to have all the answers to start. You only need all the answers to finish.
When open issues remain on backlog items are brought into a sprint, there will be times when those items are not finished in the sprint. That's okay. It’s OK (and expected) to not finish everything every single sprint. What’s not OK is slowing work down by trying to think of everything up front.
Just like in a quiz show, the answers will come eventually. And, just like in the show, sometimes those answers will fail to appear before the timer runs out [on the sprint]. As one of the contestants quipped, “I am prepared to fail spectacularly!”
But even if they sometimes fall short, teams will do a lot of learning while they search for those answers. They’ll learn about the product, yes, but they’ll also learn a lot about how to work together, how to communicate, and how to embrace uncertainty. And that learning is key to ultimately succeeding with agile.