How a simple formula proves you value output more than results.
I will admit, Don Reinertsen’s Principles of Product Development Flow sat on my shelf unread for months. Though I came across many references to this work over the past several years, almost all were accompanied by a warning — the book was dry, boring and filled with complex formulas. Not in need of a sleep aid — two kids and running a business do a sufficient job of driving me to exhaustion daily — I moved this book lower in my queue in favor of some easier reads.
I wish I hadn’t. The book ended up providing a missing link to a problem that is systemic within the industry I work — Reinertsen had pointed me towards mathematical proof why Work In Progress (colloquially referred to as “WIP”) was literally crushing every organization I had been a part of for the past two decades.
While Reinertsen’s no nonsense approach, which is grounded in the principles of math and physics, could indeed be considered dry, anyone who has spent time struggling with the issues of flow through large complex systems like I have will find this book anything but boring. In fact, this book has literally spawned a cult-like following among coders, product managers, executives and coaches — a group dedicated to improving business outcomes and achieving results with speed and efficiency. Each year at FlowCon France, people gather from around the world to share their experiences applying Reinertsen’s principles and advancing the art of delivering business value to customers.
The most groundbreaking aspect of Reinertsen’s approach is the way in which he combines principles of physics and mathematics to describe and explain the behavior of value delivery through complex systems. For those of you, who, like me, have been disciples of Eliyahu Goldratt and the Theory of Constraints (ToC), this book will be particularly illuminating. Reinertsen advances Goldratt’s approach and even dispels some false conclusions that have been widely accepted as truth for decades. For example, he is able to apply queue theory to demonstrate that there are often more effective methods to accelerate delivery than simply “exploit the constraint” — a principle central to ToC and most of Goldratt’s work.
Overall, Reinertsen outlines over 200 principles in the areas of economics, queues, variability, batch size, WIP, flow fast feedback and decentralization. All are practical and insightful — and delivered with remarkable efficiency via a book that is less than 300 pages. In fact I suspect it’s the density of information that may cause some readers to shy away from this book, but those of us in the trenches who are living these challenges daily will appreciate the economical approach.
The principle I want to discuss here is perhaps one of the simpler insights that Reinertsen puts forth. In his chapter regarding queue management, he first introduces the concept of a cumulative flow diagrams (CFD) to monitor the size and variability of a given queue. The CFD simply plots the quantity of items arriving in a queue alongside the quantity that are leaving the queue against time. The result is a simple x-y plot that looks like this:
Above, I’ve created a simple example of a CFD for a system that accepts 5 work items a day and completes 2. To determine the queue size on a given day, one must simply calculate the difference between the two cumulative numbers. In this example, the queue size is three on the first day and increases by three each day thereafter. The growing queue size can easily be seen at a glance as the cumulative arrivals grow in distance on the y axis from the departures. To determine average time in queue, one holds the number of work items constant and takes the difference between the amount of time for arrivals to equal departures. Here, the average time in queue starts out at 2.5 days and gradually increases as the queue size grows. If the rate of arrivals and departures stays the same, the average time in queue will grow to 25 days by the 10th day.
Reinertsen next explains that underlying the relationship between queue size and throughput is a well known formula in the world of queue theory known as Little’s Law. Little’s Law states simply that the size of a queue (L) will always be equal to the processing rate multiplied by the average wait time. If we interpret the average wait time as lead time and queue size as WIP, Little’s Law can be rewritten as:
Anyone that has ever worked on a program with a large feature backlog probably recognizes how incredibly powerful this is. When I came across this for the first time I had to reread the section multiple times to make sure I wan’t missing something. For some reason, it felt too simple, though in hindsight was something I had intuitively understood all along. For example, I recently worked on a program that was simultaneously working on 140 features and was managing a backlog with another 300 or so waiting to be worked. The organization was using Scaled Agile Framework (SAFe) and had just completed a Program Increment (PI) where they completed three of these features despite having committed to completing thirty. On the heels of this performance, in preparation for an audit, the Program Management Office (PMO) instructed us to “complete backlog elaborations on the entire feature backlog” (If you’re wondering what that means, so was I… suffice it say this organization was running their own version of “Agile” and was still following a heavy design up front approach). As I considered this request in light of the recent performance, I responded that this would certainly be a colossal waste of everyone’s time. Besides I remarked,
by the time we get halfway through this backlog, won’t most of us be dead?
At first I couldn’t understand why everyone wasn’t on the same page with me: we had over 400 items to finish, 300 hadn’t been started, and, based on the throughput for the last three months, we were on pace to complete about twelve in a year. Doesn’t this mean we have at least 30 years of work on the backlog? And since we have only three years left on the contract to do this, we’d need to increase our throughput tenfold, starting now, right?
My assumptions weren’t going over well at all with the organization’s leadership. Some of this was denial — yes, we completed three out of the thirty we planned to complete last quarter, but we got unlucky. Lots went wrong. There’s no way this is going to happen again. But there was a deeper misunderstanding at play, a belief that I wasn’t able to move them off of.
Our leaders believed that the best way to get back on track was to start more work.
As an interesting aside, I should point out that this organization had “gone Agile” six years prior with apparently no interest in speeding up the feedback cycle. They seemed to be under the belief that handing out titles like Scrum Master and Release Train Engineer, and holding daily scrums would somehow magically produce results that could be measured in terms of productivity and output. The PMO held story points as their key indicator. Demonstrations were sometimes held at the end of each sprint, but nothing in the backlog was ever changed as a result. To top it off, the PMO defined a story point as “the amount of work that can be completed by an agile team in 8 hours.” So, they were literally measuring their progress in terms of the passage of time.
I digress on this point only to underline the systemic issue at play that plagues many, if not most organizations that adopt Agile frameworks under the false assumption that it will make them more productive. Few leaders understand that productivity is not the goal. If productivity increases as a result of an Agile transformation that’s a wonderful by-product, likely related to the increased happiness and flow that accompanies such a transition executed correctly. I’ve come across very few people that understand this.
The real goal of Agile is to get the desired result with the smallest amount of production humanly possible.
This is of course achieved through fast feedback — which gets an entire chapter by Reinertsen and perhaps may be a relevant topic for a future blog post.
But back to the 400 item backlog. If I were aware of Little’s Law six months ago, would my argument have been any more convincing? Perhaps. I could have proven that starting more work will only increase the lead time for each work item if the throughput stayed the same. But lead-times were irrelevant to this organization because feedback was never considered. What was important was that everything magically completed in three years. It had to work, meet the requirements that were written years prior, and satisfy the contract, user be damned.
So how does Little’s Law help an organization such as this?
Keeping the math simple, let’s say that the goal is to complete 300 features in three years, and the organization currently completes twelve a year. One organization tackles this by starting everything at the same time. Using Little’s Law and the current throughput tells us the average lead time for each item will be twenty five years. Some things might finish sooner than that, but on average, each item will take two and half decades to eek its way through the development pipeline.
Now what if another organization does everything the same but sets a WIP limit of 3. Will they finish any sooner? Well, if throughput remains constant at twelve features each year, the newly assigned WIP limit produces a lead time of 3 months per item. Now, users get their hands on features more than two decades sooner. However, if there is no driving need to obtain user feedback, shortening the lead times produces little value. Will they be done any sooner? No. Throughput hasn’t changed, only lead times. Lead times are of the highest important for an Agile organization, but not very important at all for an organization that still has a waterfall mentality — no matter how many Scrum Masters and daily Scrums it has.
At this point you’re probably asking what my point is.
I suppose my point is that absent feedback and learning, there really is no point to any of this.
What I mean is, absent feedback and learning, you can throw SAFe, Agile, DevOps, Lean — and Reinertsen’s so-called “bible of Product Development” into a trash can and set it all ablaze with the rest of those books we read so that we can talk the talk. We can talk all we want, but it’s going to be Groundhog Day until we wake up to this truth that so many have realized for years.
The value in shorter lead times is faster feedback. Faster feedback produces more opportunities for learning. Learning leads to improvement. What Little’s Law tells us indirectly is that limiting WIP makes you better. Not only do shorter lead times enable user feedback, but they also allow developers to learn better ways to work — particularly better ways to complete work. In the example above where the WIP limit was set at three, teams will practice completing work items 100x more frequently than they would if they started everything at once. That’s 100x more opportunities to tackle the most challenging piece of development — making the code work! Starting everything at the same time and getting it to work at the end would be like practicing soccer by dribbling the ball 20 miles each time before you take a shot. You’d get really good at dribbling, but you’d get very little practice on the part that delivers an outcome — assuming you don’t give up from exhaustion or frustration by the time you get to shoot.
This is what Gene Kim was talking about in his five principles of DevOps outlined in the Unicorn Project. Gene’s second principle is focus, flow and joy. Joy results when a team is empowered to dribble, pass and shoot on a regular cadence. Maybe not all shots hit the net, but the team has the opportunity to score a goal. They own the outcome. When we instead decide to measure teams by story points or lines of code, we rob them of that joy. And we remove any opportunity to learn and improve.
So next time your backlog starts to grow uncontrollably, don’t panic. Remember Little’s Law. Remember that feedback and learning move inversely with lead time. And don’t forget to shoot.