Gathering Agility.

Who's Your Enemy? Little's Law for Managers

Cover Image for Who's Your Enemy? Little's Law for Managers
Roger
Roger

Who's Your Enemy? — Little's Law for Managers

"You should back some work off your teams."

I had given this advice to numerous clients, but this time you could almost feel a chill creep into our virtual meeting. I was chatting with managers and directors from a large company in the middle of an Agile transformation. I was there because executives were concerned that they were falling behind their competition. Projects were limping along for years, only to be abandoned well before realizing any value. They were already losing out to more nimble competitors, and they feared the next few years might jeopardize their position as a market leader.

"Back some work off your teams. You’ll get more done that way."

From the reaction, you would think I had suggested that attendees take a shotgun to their left foot.

"That’s not possible. We’ve made commitments," said one director.

This division had a list of thirty four projects, each assigned a priority from one to three. There were fourteen projects in the “priority one” bucket. Everything was due within the current fiscal year. Any of the projects on their list, I knew, might take eight months of concentrated effort from multiple teams. But concentrated effort was unlikely to happen. Every other week, it seemed, executives called large meetings where they introduced yet another urgent projects. They demanded deadlines, which needed to be within the next four quarters. I had seen this pattern often enough to know that this behavior, left unchecked, would easily turn an eight-month project into a half-hearted three-year effort that never sees the light of day.

"Look," I said. "You have too many top priorities. Your organization is chasing shiny objects. I understand the need for urgency, but if everything is an all-hands-on-deck-must-have, then nothing is. You have to make some choices, and that means choosing what not to do."

"But we’ve made commitments to the business," said the same director.

I genuinely liked this group of people. We had a great rapport as we talked our way through their first project-to-product transition. This was fun, creative work, and they seemed engaged and excited by the possibilities. But that fun always stopped short. It was like hitting a wall. They had the hardest time seeing past that list of thirty-four projects, each one with its own fantastical commitment date.

I sighed.

"Listen," I said. "I know you’ve made promises, but you’re not going to keep any of them unless you back work off. That will be a difficult conversation, but you’re not fighting me over this. I’m just the messenger here. Your real enemy is math."

Meet Your Enemy

When it comes to work produced by teams, the single most interesting question for most managers is "When is it going to be done?" (Although usually, let’s admit, it’s usually phrased something like "Why the hell aren’t our teams getting anything done?") Fortunately for all of us, there is a brain-dead simple equation that answers this question for us: Little’s Law. Here’s what it looks like:

By Christoph Roser at AllAboutLean.com under the free CC-BY-SA 4.0 license.

By Christoph Roser at AllAboutLean.com under the free CC-BY-SA 4.0 license.

The three terms in Little’s Law are as follows:

  • L - the length of the queue. For the purposes of software development, we can think of this as the number of stories to be delivered.
  • λ - the throughput, represented by the pressure gauge
  • W - the lead time, or the average time every item in the queue will spend in the system

The water tank analogy, used in Reinertsen’s book The Principles of Product Development Flow, simplifies the equation very well. If we want to know how much water is in the tank, we can simply multiply the rate at which water flows through the tank by the time the water spends in the tank. In the same way, the size of the queue of work into our teams is easily determined by taking the team’s average throughput (typically user story per day) and multiplying by the average time it takes to complete any item currently in the queue.

But this does not yet answer the question, “If I add a new item to this queue, how long will I have to wait for it?” To determine this, we can rewrite the equation to isolate our wait time.

W eq L over lambda

Let’s take a quick example. Let’s say a team has four user stories waiting to be worked. The team can usually get user stories completed in about three days. Every week, the team’s manager stops by to drop off three more user stories. Here is what happens.

W eq 21

By the end of week one, the team has completed one story, and is two thirds of the way through a second. Four more stories are added to their queue, which bulks up the wait time to 28 days. That may not seem like much, but you have added just shy of a week and a half to the wait time. Unless something fundamentally changes in either the queue length or the throughput, the time it takes for teams to complete what is expected of them will continue to grow linearly.

graph

This rate of growth is simply not sustainable, unless you have no interest in seeing the team actually complete anything.

Faced with this dynamic, a lot of managers resort to putting pressure on their teams. Clearly, the team’s utilization needs to be increased. They can work weekends, or stay up late. Sorry to say, math is against you here as well. The equation at work here is Kingman’s formula. It is used all the time to monitor server load in networks, and here it tells us that trying to squeeze extra utilization out of teams results in an exponential slow-down.

utilization graph

I hope to study this calculation more in a subsequent post.

The Lesson

So what is the answer for the group of managers? The first thing is to understand that the promises made to the business were garbage. That list of thirty-four features? You can immediately get rid of the bottom twenty of them, if not more. Absent the power to bend time and space, this company simply did not and does not have the available capacity to deliver that much within the current fiscal year. We can get into the cultural forces that prevent the leadership of large organizations from acknowledging the obvious. That is a topic for another time.

What we can understand is that trying to reshape reality to our whims is probably not a sound way to run a business. And while it may sound obvious, try not to pick a fight with math. The odds are not in your favor.