The #NoEstimates Debate

3,743 views

Published on

My talk at Agile Singapore and Agile Scandinavia.

Published in: Technology, Business

The #NoEstimates Debate

  1. 1. to Agile natives Alter and... timation Es the #NoEstimates debate Neil Killick, Agile Coach / Trainer neilkillick.com / iterative.com.au Copyright Neil Killick, Iterative, 2013 neil_killick
  2. 2. What isWHAT IS #NoEstimates? Like “Agile”, it has come to have many definitions and interpretations.
  3. 3. Birth of #NoEstimates A conversation, started on Twitter, about ways in which software can be delivered with no estimates.
  4. 4. What drove the debate? A collection of opinions and practical advice from practitioners who deliver software with no estimates.
  5. 5. It’s now become... A diverse and much needed debate about when it is appropriate to use estimates in software, and what form these should take.
  6. 6. The #NoEstimates Crew Woody Zuill Neil Killick Vasco Duarte Chris Chapman Henri Karhatsu
  7. 7. Common Ground WHAT IS EMBRACE AGILE PRINCIPLES FOCUS ON VALUE DELIVER SMALL SLICES DELIVER EARLY & FREQUENTLY CUSTOMER COLLABORATION
  8. 8. 3 E’s of #NoEstimates thics mpiricism mergence
  9. 9. ETHICS - Cycle of Mistrust Deliver the wrong thing, or late Trust breaks down Focus on schedule Commitments of scope and time
  10. 10. EMPIRICISM - Working software allows us to monitor progress and manage risk in a new way.
  11. 11. EMERGENCE of cost and value as we get feedback from users and market.
  12. 12. Predictability Which is more predictable -A team that estimates or one that doesn’t ?
  13. 13. Team #Estimates DETERMINISTIC AND REACTIVE FOCUS ON SCHEDULE / PLAN SCOPE DRIVES DECISIONS LOTS OF WIP IN ATTEMPT TO “GET IT ALL DONE” ● NO METRICS, OR INAPPROPRIATE ONES ● ● ● ●
  14. 14. High variability 12 days 1 Day
  15. 15. Team #NoEstimates ● ● ● ● ● PROBABILISTIC AND PROACTIVE FOCUS ON TIME AND CASH CONSTRAINTS ITERATE DESIGN AND DECISIONS DELIVER WITH FLOW / LIMIT WIP ACTIONABLE METRICS (e.g. STORY CYCLE TIME DISTRIBUTION) USING A “SLICING HEURISTIC”
  16. 16. Better Predictability 3 days 1 Day
  17. 17. What’s a TM “Slicing Heuristic ”? ● EXPLICIT POLICY FOR BREAKING DOWN WORK AND MEASURING HOW LONG IT TOOK (CYCLE TIME) ● STARTS AS A SHARED DEFINITION OF WORK TYPES (e.g. THEME, FEATURE, STORY, etc.) ● SLICE ALL UPCOMING WORK SIMPLY AND SYSTEMATICALLY FOR “SMALL-NESS”
  18. 18. Example Max 1 User Scenario ● Given Bob is a registered user, When Bob logs in Then he should be logged in. ● Given Bob is logged in, When Bob chooses Profile Then he should see his profile.
  19. 19. Slice into 2 separate stories
  20. 20. Slice those stories further
  21. 21. Why use a Slicing Heuristic? ● Agility relies on small chunks, so useful to have a consistent and explicit way of creating them ● Improve ready-ness and done-ness ● Focus on delivering more frequent slices of value ● No need to explicitly estimate or re-estimate
  22. 22. Why use a Slicing Heuristic? ● Story points are ambiguous, time isn’t ● Explicit policy, so can be inspected and adapted to narrow control limits ● Outliers can be addressed at standup or retro
  23. 23. Slicing creates options ● Exposes goals from solutions and vice versa ● Slices not necessarily “smaller” than thing we sliced, but multiply our options
  24. 24. Portfolio #NoEstimates KEEP TEAMS TOGETHER ENABLE CONTINUOUS DELIVERY NO LONG PROJECTS / PROJECT THINKING DRIP FUND (MULTIPLE OPTIONS) BUILD THINGS ON DEMAND, DELIVER AS SOON AS THEY ARE READY ● FLEXIBLE CONTRACTS ● ● ● ● ●
  25. 25. Choosing what to do Present a business case Is initiative still valuable enough? YES NO Stop Approved as viable option Timeboxed experiment y eliver d uent Freq back loop feed & + Team(s) if required Initiative prioritised Team assigned
  26. 26. Scaling up and down
  27. 27. Questions
  28. 28. Question 1 What is and isn’t estimating, given people form and act on expectations of an uncertain future every day?
  29. 29. Answer 1 ● Estimating = Giving ranges of actual or relative time based on past observation, WIP, team size, etc. ● Guessing = New teams, with competing priorities, asked to give single dates in unfamiliar domains ● There is nothing intrinsically wrong with estimating, so long as we: ○ Understand its limitations ○ Use it only in appropriate situations ○ Don’t rely on it for big up front decision making ○ Update our estimates (and everyone’s expectations) based on real data frequently
  30. 30. Question 2 Why would we choose not to judge likely outcomes if worthwhile human endeavours necessarily carry risk?
  31. 31. Answer 2 ● #NoEstimates is about alternatives to estimating the cost of delivering software, not the value it generates ● We must hypothesise (estimate) the value of things in order to decide if we will pursue them ● My argument is that rather than estimate cost we can control (fix) it in “drips” using fixed Agile teams ● Delivery of working software allows us to reassess value iteratively based on the reality of user / stakeholder feedback and market conditions
  32. 32. Question 3 If we elect not to take on the risk of predicting an uncertain future, who do we think should, and why?
  33. 33. Answer 3 ● We should embrace the delicious uncertainty of software, be excellent in what we do and aim to delight rather than “meet requirements” ● Software products and services have ongoing value, so the final cost and value can never be known up front ● We can’t fix price and scope, but we can work collaboratively and continuously with our customers to build the best possible result for budget or time constraint ● We can provide flexible pricing and termination options to our customers based on similar past work
  34. 34. Question 4 Off the shelf library software costs $50k. We could try building our own at $2,500/day but might fail. What should we do?
  35. 35. Answer 4 ● Answer depends on many things like whether we have an established team, are we capable of delivering features every few days, etc. ● Need to establish the problem rather than decide between solutions; Do we need the software at all? ● What are the consequences of spending more than the OTS product costs? Is the $50k a constraint? ● How would ongoing maintenance costs compare?
  36. 36. Answer 4 (contd) ● 4 weeks not far into the future, so probably have an instant sense of “Is it possible?” and “Can we build something better?” ○ ○ ○ ○ Do we know enough about the domain? What are minimum features we need? How many people do we have? Do we have any other WIP?
  37. 37. Neil Killick, Agile Coach / Trainer neilkillick.com / iterative.com.au Copyright Neil Killick, Iterative, 2013 neil_killick

×