Table of Contents
Daniel Vacant - Why Winning the Lottery is More Predictable Than Your Agile Project
Premise
“When will it be done?” That is the first question your customers ask you once you start work for them. And, for the most part, it is the only thing they are interested in until you deliver. Whether your process is predictable or not is judged by the accuracy of your answer. Think about how many times you have been asked that question and think how many times you have been wrong. Now think about how much harder it is to answer that question when practicing Agile at scale. Your customers most likely feel like they have better odds of winning the lottery than they do of your next Agile project coming in on time. That you don't know your odds of success is not necessarily your fault. You have been taught to collect the wrong metrics, implement the wrong policies, and make the wrong decisions. Until now. This session will introduce how to utilize the basic metrics of flow to more effectively manage the uncertainty associated with very large scale software development. In it, we will discuss how to leverage the power of advanced analytics like Cumulative Flow Diagrams, Cycle Time Scatterplots, and Monte Carlo Simulations to drive predictability at all levels of the organization. Your customers demand better predictability. Isn’t it time you delivered?
Learning Outcomes:
A meaningful understanding of the basic metrics of flow (WIP, Cycle Time, Throughput) How to apply flow metrics at all levels of the organization How to visualize flow metrics in advanced analytics like Cumulative Flow Diagrams and Scatterplot How to interpret those analytics as guides for process intervention for predictability
Summary
- Content rating (0-no new ideas, 5 - a new ideas/approach, 9-new ideas): 9
- Style rating (0-average presentstion, 5 - my level, 9-I learned something about presenting): 6
Action / Learning
- Contention is that “when” question is answered by cycle time.
Presentation
Read book Actionalable Agile Metrics for Predictability
Speakers Daniel Vacanti - CEO, Corporate Kanban, now with actionable agile Bennet Vallet - Principal Consultant, ActionableAgile.com
Notes
Let's talk about odds in general
Shark attack Vs Winning lottery
Lottery Vs Asteroid
Lottery Vs Software project come in on time
Guess is that we don't know Which means the lottery is better bet as at least we know what the odds are
Why don't we know our odds?
What's first thing people When done? Expect date (number of days) Elapsed calendar time - how do we communicate
How do we estimate Story points and velocity
See video - communication mismatch - ask for date, answer in story points Siri - Scottish interpretation Apple Scotland having a wee bit of trouble
Why story points? See video - British cat hypnotizes pit bull Message - we've been hypnotized
“When will it be done” should be answered by “cycle time” Cycle time - elapsed time for a given work item to be complete Items arrive (start clock) - items leave (clock stops)
Customer cares about this.
How long will something take biggest influencer Wip
Average cycle time = average wip / average throughput Total time between start and stop as wip
What if we could visualize this
There is cumulative flow chart Based on status Calendar time versus cumulate work item count
Here phone - “is that for me”
Vertical distance is wip Horizontal distance approx average cycle time
Approx As stuff in out might be different
Most stuff talked about cfd is wrong
Slope of bottom line is average throughput Slope of top line is arrival rate
Early In process wip is smaller as average cycle time increases - littles law
Want arrival rate parallel to departure
Necessary first step to become predictable And so can calculate odds
Use this as an objective based retrospective
Click presentation data Actionableagile.com/agile2015
Look at first two months - plan with chart See arrival vs departure rate - arrival faster than departure How make prediction if divergent
See retrospective presentation
Works at all levels of the organization Stories, features, projects
Average cycle time is not enough
Need cycle time
Another chart Calendar time vs cycle time (actual) - build a scatter plot
Looks like a random set of dots
How can we harness it
Scatter plot percentiles (Don't do average or sd) - see Troy
Draw lines 50% of dots below the line 50% above 19 days on the chart 50% chance of finishing in 19 days or less
Do for horizontal 85% at 43 days 95% at 63 days
How factor in size Size doesn't matter Biggest thing that matters is wip
Requires some notion of system stability Team size etc Else filter the data
How do we know if cycle time is stable?
Triangle of death Things are taking longer over time This is what happens when you don't watch wip
Flat scatter plot is “ok”
What happened around oct 1st on the diagram Start controlling wip
Calculating odds of delivery Single item very simple Use the “how much of the risk are you will to live with” Wrong 50% of the time then date is X
Lean approach to uncertainty is not do more analysis. It is to do some work.
General approach to improvement: Make parallel Make the lines closer How move up
How forecast multiple items How many stories in the release How long will it take
Best measure is thruput
Monte Carlo simulation Controlling wip / cycle time now can use this data
Choose historical thruput on chart
Go back to chart - Monte Carlo simulation date With 95 % confidence Change - assume first part of chart dec release Control wip - regent chart done by nov release All we did was watch wip limits
Here are our odds.
To sum up Now better than lottery
If triangle of death or convergent arrival rate then cannot predict as unstable
Book - book with actionable metrics from lean pub
Implement first at the team level But could also start doing at the program level Even if you do it at team level may still of issue at higher level. Have to do wip at all levels.
If you do at the story level can you do at the feature level You have the relationships.
We would hit the dates Look at metrics and do something.
Why doesn't size matter Because we care about elapsed time Most of the time is spent in queues - not doing action on something You can estimate effort but not variability.