User Tools

Site Tools


daniel_vacanti_-_why_winning_the_lottery_is_more_predictable_than_your_agile_project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

daniel_vacanti_-_why_winning_the_lottery_is_more_predictable_than_your_agile_project [2016/07/03 13:38]
daniel_vacanti_-_why_winning_the_lottery_is_more_predictable_than_your_agile_project [2020/06/02 14:22] (current)
Line 1: Line 1:
 +====== 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 [[https://leanpub.com/actionableagilemetrics|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.
 +
 +{{tag>Estimation Conference Forecast Planning Metrics}}