“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

• 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

• Contention is that “when” question is answered by cycle time.

Read book Actionalable Agile Metrics for Predictability

Speakers Daniel Vacanti - CEO, Corporate Kanban, now with actionable agile Bennet Vallet - Principal Consultant, ActionableAgile.com

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.