A Little’s Law Mindset

An Agile production framework can be thought of as a system of delivery based on producing in small batches that are amenable to inspection and adaptation for the purpose of iterating towards an optimal solution.

The fundamental enablers of this approach are:

• Small, cross-functional teams with all skills needed to independently produce working software as the output of each sprint.
• Product Backlogs created in a way that supports both clarity and flexibility – user stories.
• A set of practices that support the ability to produce valuable product increments as the output of every sprint. This generally needs a level of CI and Test Automation in place as a supporting prerequisite.

It is then tragic if, having been beautifully agile through the development process, code then sits around waiting for legacy release and deployment practices. New product capabilities or improvements are of zero value until they reach the hands of users.

A goal of DevOps is to achieve an uninterrupted flow from development right through to deployment, operation and support. Lead Time is the key metric, and DevOps teams seek to relentlessly improve it. Tooling and automation play a significant role in this process.

True value is realized when we get beyond ‘working/tested software’ to ‘working/tested/deployed’ software, that is, software in the hands of actual users.

Delivery Lead Time measures the time from request (for a service or a product feature) to delivery. Little’s Law describes the factors that determine the result.

Little’s Law can be stated:

Delivery Lead Time = Length of Input Queue (WIP)/Production Rate

• The numerator in the equation is the amount of work queued up in front of the item to be processed. This can be applied to the entire end-to-end process, or for any individual step within the process. Ideally we would have a maximum of one item queued, in which case we would have a one-piece-flow situation where only one piece of work was processed at a time. There would be no steps where work was delayed or waiting for work ahead of it to be processed. In this ideal case the amount of work in the system,  WIP = 1. The numerator is Little’s Law can be heavily influenced by basic workflow design, team structures and work item variability – anything to minimize the build up of queues, buffering of work within the workflow. This is where change can be enacted fastest.
• The denominator in the Little’s Law equation is the processing time per item or production rate of the system. The larger (faster) this value the shorter the Lead Time. This parameter can be improved in 2 ways:
  • Remove non-value-adding work (waste) from the processing steps (all of the classic 7 sources of waste from Lean: fixing defects/re-work, over production, over processing, unfinished goods (WIP), non value-adding steps, and so on).
  • Increase production capacity and speed: more equipment, more automation, tooling improvements, more people. These improvements are likely to take more time and more investment.

Here’s another way to think about it:

When deciding on any course of action to improve a process, for example in a retrospective, it is worth considering how that action impacts either the numerator or denominator of Little’s Law. (If it affects neither it’s probably a waste of time).

Don Reinertsen advocates making prioritization decisions based on Cost Of Delay, (see here), that is, overall life cycle profit impact. This can bring clarity to decisions about whether to prioritize based on minimizing cost or reducing development lead times. Reinertsen’s WSJF (Weighted Shortest Job First) method can help reduce WIP by forcing a stack-ranking approach to work scheduling. (Someone described ‘Priorities’ as The Last Refuge of the Innumerate).

Lead Time is an example of a flow metric. Flow is a measure of how effective an organization is at delivering value. Relentless Improvement, one of the Lean principles, is focused on improving flow.

A Little’s Law Mindset is a Flow Mindset. Being conscious of Little’s Law when considering any improvement action is a kind of Agile Mindset.