Agile Transformation

Electronic boards for agile teams Martien van Steenbergen 29 Aug, 2011

Have you ever used Little's Law to explain that lower WiP (work in progress) limits lead to shorter cycle times? Ever tried to illustrate Little's Law in an Agile game and found it doesn't hold? Then read this blog to discover that it is exactly true in Agile games and how it really works.
Some time ago I gave a kanban workshop. Part of the workshop was a game of folding paper airplanes to illustrate flow. To illustrate Little's Law we determined the throughput, cycle time and work in progress. To my surprise the law didn't hold. Not even close. In this blog I want to share the insight into why it does work! ## Introduction

It is well known that the average number of items in progress is proportional to the average cycle time of completed work items. The proportionality is the average input rate (or throughput rate) of work items. This relation is known as Little's Law. It was discovered by Little in the 1960s and has found many applications.
In kanban teams this relationship is often used to qualitatively argue that it is favourable for flow to have not too much work in parallel. To this end WiP (work in progress) limits are introduced. The smaller the WiP the smaller the average cycle time which means better flow.
A surprise to me was that it is exactly true and it remains true under very relaxed conditions.## Little's Law

In mathematical form the law is often stated as:
(1) \[ \bar{N} = \lambda \bar{W} \]
Here \( \bar{N} \) is the average number of work items in progress at a certain time, and \( \bar{W} \) is the average cycle time. \( \lambda \) is the average input rate (new work items per unit of time). In stable systems this also equals the average throughput. In this case Little's Law is often (re)stated as
(2) \[ \frac{\mathrm{Work\, in\, progress}}{\mathrm{Throughput}} = \mathrm{Cycle Time} \]## Conditions

In practise one considers Little's Law over a finite period of time, e.g. 6 months, 5 sprints, 3 rounds in an Agile game. Also in practise, teams work on backlog items which are discrete items. After the work is done this results in a new product increment.
Under the following conditions (1) is exact:*Examples of a queueing **system*. An agile team works on backlog items. A kanban team that works on production incidents. A scrum team.## Agile Game

An often used game for explaining the importance of flow to team is the game of folding paper airplanes. Many forms of this games exist. See e.g. [Heintz11].
For this blog's purpose consider a team that folds air planes. The backlog is a stack of white paper. 3 Rounds of folding are done. Airplanes that are folded and fly at least 2 meters are considered done. At the end of each round we will collect the following metrics:## Calculating Little's Law

The way I was always calculating the number for work in progress, throughput and cycle time has been## The Truth

The interpretation of work in progress, throughput and cycle time I got from working with cumulative flow diagrams. There are many resources explaining these, see e.g. [Vega2011].
The key to the correct interpretation is choosing the time interval for which to measure the quantities \( \bar{W} \), \( \lambda \), and \( \bar{W} \). Second, using the input rate instead of the throughput. Third, at the end of the time period include the unfinished items. Last, in calculating \( \bar{N} \) consider *all* items that went through the system.
When we reinterpret the results for teams A and B we get **Team A****Team B** In a similar manner the reinterpreted results for team B are:*Note*: the cycle time of 10 days is built up by (a) 1 airplane from round 1 (cycle time of 3), 2 airplanes picked up in round 2 (total of 4 rounds), 3 airplanes picked up in round 3 (total of 3 rounds).## What About Cumulative Flow Diagrams?

Now that we understand how to calculate the quantities in Little's Law, we go back to cumulative flow diagrams. How come Little's Law works in this case.
In the case of teams that have collected data on cycle time, work in progress and throughput Little's Law work when done as explained in the section 'Calculating Little's Law' because:## Summary

Little's Law (1) holds under the conditions that (a) the system considered is a queueing system and (b) the observation or measurements are done over a finite time interval. It then holds independently of the stationaryness of the probability distributions, queuing discipline, emptiness of the system at the start and end of the time interval.
Calculate the quantities \( \bar{N} \), \( \lambda \), and \( \bar{W} \) as follows:## References

[Little61] Little, J. D. C. 1961. *A proof for the queuing formula: L = ãW* . Oper. Res. 9(3) 383–387.
[Heintz11] John Heintz, June 2011, *Agile Airplane Game,* GistLabs, https://gistlabs.com/2011/06/agile-airplane-game/
[Vega11] Vega Information System Services, Inc., September 2011, *Basics of Reading Cumulative Flow Diagrams*, https://www.vissinc.com/2011/09/29/basics-of-reading-cumulative-flow-diagrams/

- The system is observed over a finite period of time,
- The system is a queueing system.

- number of completed airplanes
- number of airplanes in progress and not yet finished.

- averaging cycle time for all completed airplanes,
- averaging the throughput over all rounds,
- averaging the work in progress over all rounds.

- Average work in progress = (8+6+2)/3 = 16/3,
- Average throughput = 10 (completed airplanes)/3 = 10/3,
- Average cycle time = 22/10 = 11/5

*Average work in progress*In round 1 3 airplanes were completed and left 8 unfinished; a total of 11 for work in progress (11 airplanes picked up as work) In round 2 the team completed 2 airplanes and have 6 unfinished; a total of 8 In round 3 the team finished an additional 5 airplanes and left 2 uncompleted; a total of 7 When measured over 3 rounds an average of (11+8+7)/3 = 26/3*Average input rate*Using the input rate: In round 1 the team picked up 11 new airplanes In round 2 the team picked up no additional airplanes In round 3 one new airplanes was picked up. An average input rate of (11+0+1)/3 = 4 airplanes per round*Average cycle time*At the end of the third round 2 airplanes are left in progress; one taken up in the third round having a waiting time of 1 and one left from the first round having waiting time of 3 rounds. A total waiting time of 22 + 3 + 1 = 26 rounds. Averaging over 12 airplanes we have an average cycle time of 26/12 = 13/6 rounds per airplane.

*Average work in progress*= (13+14+10)/3 = 37/3 airplanes,*Average input rate*= (13+2+3)/3 = 6 airplanes per round,*Average cycle time*= (27 (completed) + 10 (unfinished))/18 (airplanes) = 37/18 rounds per airplane

- the teams are kept stable by having WiP limits on the left most column ("To Do"); then the throughput is more or less equal to the input rate,
- the team has completed a fairly large amount of work items in which case the waiting time of unfinished work items can be neglected,
- when measured over the (large part of the) value creation process, the completed items per time period can often be neglected in the calculation of the average work in progress.

*Average work in progress*\( \bar{N} \) For each time interval considered count the total amount of work in the system and add any items completed in that time interval.*Average cycle time*\( \bar{W} \) Sum the cycle times for all completed items and include the waiting time for unfinished items and divide by the total number of items.*Average input rate*\( \lambda \) Add the total number of items that entered the system and divide by the total number of time intervals.

Agile Transformation

Electronic boards for agile teams Martien van Steenbergen 29 Aug, 2011

Agile Transformation | Software Development

How Agile accelerates your business Daniel Burm 25 Jun, 2014

Agile Transformation

Agile Toolkit Evelien Roos 23 Nov, 2018