“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Agile Manifesto, Principle #3

Agile development is iterative development, with work divided into Sprints, increments or development cycles. These iterations can last from one week to eight weeks, but most teams have Sprints of two to four weeks. That allows teams to plan a reasonable amount of work, but not get further ahead than they can see.

At the end of a Sprint, Agile methods have a demo, a release or both, to provide a vehicle for delivering working software that is “done-done.” The expectation is that teams will be able to drive the work they’ve planned to full completion, so that they can move on to new work in the next Sprint.

From the beginning of this series, we’ve emphasized that the value delivered at the end of a Learning Cycle is different than the working software delivered at the end of a Sprint. For physical product teams, the value they deliver is the knowledge needed by their decision makers to make decisions and by their downstream partners to produce, maintain and support the product. This knowledge also benefits from being delivered frequently.

It’s obvious to most people that frequent deliveries increase agility: it provides a mechanism for incorporating feedback, new information and course corrections if necessary. But there’s more to frequent deliveries than just feedback.

Frequent Deliveries Improve Workflow

To really understand why frequent deliveries improve workflow, we need to dive into queueing theory. This body of work explains the effects we see on highway systems at rush hour that cause traffic jams. It’s been used to design bank lobbies and internet networking systems. It explains why many Agile practices work — especially the Agile practice of frequent deliveries.

In my first article in the Agile Principles series, Early Continuous Delivery of Value for Physical Products, I explained why continuous delivery improves flow, and described how batch sizes work. Queueing theory provides a mathematical foundation for exploring the effects of different batch sizes and batch size variation on queues. But you don’t need the math to understand that in general, small batch sizes flow better through a system than large batch sizes and that’s the key thing that frequent deliveries provide.

But the frequency is only part of the reason why Agile methods work. Queueing theory also explains why a regular cadence of delivery is key to achieving agility.

Cadence: The Missing Agile Principle

The Agile principles themselves don’t mention cadence. But there’s a reason why every major variant of Agile assumes that Sprints will have the same length: regular cadences keep systems synchronized, which helps pull teams into alignment.

Cadence is a regular rhythm, like the ticks of a metronome. Cadences have the superpower of synchronization: the conductor moves a baton in a cadence to keep an orchestra in sync, and a well-balanced factory moves components and subassemblies down the line in a regular, predictable cadence to maximize flow. But we don’t have to rely upon our own observations.

Queues Disrupt Flow

Anyone who’s waited in line for the restroom or at a bank has experienced the effects of a queue on flow. Queuing theory has demonstrated that queues get longer when the items in the queue arrive at unpredictable times, and when the items arrive in large batches. The more variation there is in the intervals between arrivals, the longer the queue will be. A big batch necessarily creates a queue, the way intermission in a theater creates a queue for the women’s bathroom.

It always takes longer to eliminate a queue than it did to create the queue, since the step with the lowest capacity (the bottleneck) determines how long it takes. We see this in busy cities where traffic backs up quickly in trouble spots as the morning commute begins but may not flow freely again for hours, and in the way that some women are still in line when intermission ends, if there aren’t enough bathrooms.

Teams experience this as workflow interruptions: if their work changes too often, they have a hard time making enough progress on anything to finish it, and the work-in-progress queue grows. Progress grinds to a halt.

Frequent Predictable Releases Reduce Queues to Improve Flow

When a team runs Sprints and/or Rapid Learning Cycles on a regular cadence, they harness the power of reducing variability and cutting batch sizes. The team knows when new work will arrive and when changes will be made — at the start of the cycle.

They know that the amount of work they have to do will be bound by the length of the cycle — the batch size will be smaller. They can work uninterrupted during the cycle. They know at the end that they will be asked to share their work.

The predictable rhythm, with cycles of work followed by feedback, review and replanning, helps to maximize the flow of work through development, whether that’s coding software or running experiments with new materials for hardware development.

As teams gain experience, they get better at estimating how much new work they can accept without getting overloaded. For those things they can’t estimate because the work is entirely new or the needs are fuzzy, we use timeboxes.

Fuzzy Investigations Need Timeboxes

A timebox is a fixed period of time for doing work: I’ll do customer interviews for two weeks and then reflect on what happened to figure out what to do next. We use timeboxes to limit the scope, time and resources that we invest in something that doesn’t naturally have good time boundaries.

Most learning activities produce diminishing returns, and most early investigations need directional guidance, not precise answers. Knowledge Gaps in early development especially benefit from timeboxes that specify how many learning cycles a team will invest to close the Knowledge Gap before consolidating their findings and moving to the next Knowledge Gap.

The Third Principle for Physical Products

This principle works much the same way for physical products as it does for software, as long as teams recognize that they are delivering knowledge, not the hardware itself. This means that the length of the learning cycle should be tied to the team’s pace of learning, which is normally faster in early development than it is in mid to late development.

To make this principle fit physical products, we just need a few changes to reflect this:

“Deliver the knowledge needed to develop the product regularly and frequently, every two to six weeks, according to the team’s natural pace of learning.”