Measure Throughput, Not Utilization

to finish all the development.

The people on the teams are now siloed instead of working as cross-functional teams, they do not have a common definition of done, they have tons of work in process, and the developers are concerned their open defect count is growing because they are not receiving any tester feedback. The teams' velocities have decreased.

At the next retrospective, one of the developers explains the problem and that it's only getting worse. The team generates a cumulative flow diagram, as in figure 1. The technical staff and the product owners all agree: They must do something different.

Figure 1: Initial three iterations on a project with no slack

For the next iteration, they decide that an entire team will take just one feature at a time and work on it until it's done. They start with the features in the test team's queue so they, as a project team, can really finish them.

The testers explain that they don't have an automated test framework for the testing they need to do, so some of the developers collaborate and build one in a couple of hours. The test manager protests, "But, that's not going to be everything we need for the future."

A developer replies, "That's OK. We're not going anywhere, so we can refactor or change or add to it as we proceed."

It took this team another two iterations to catch up with the backlog of work in the test group. Now, they use cumulative flow diagrams to see that they are really finishing work.

Figure 2: Cumulative Flow for the rest of the project

Throughput is What Matters
It's very tempting to think of people as piece workers. It's easier to count throughput if you think a person is responsible for a chunk of work by herself. You could count that person's output and know that you were accomplishing work, but knowledge work doesn't work that way.

When you look at knowledge work as piece work, you create bottlenecks. You prevent complete feature throughput. You don't allow people to create the small tools they need for accomplishing their work, especially if they need help from others to accomplish that work. I don't know of any software development that is truly solo; all the software I know about depends on a group of people who work together to create an entire system or product.

Why is Utilization So Attractive?
Thinking about utilization ignores the reality of software products and systems, but mangers still insist on it for two good reasons. The first is that if you can assign people to many projects and make sure they are "fully utilized," then you don't have to make the difficult decisions of managing the project portfolio (i.e., which projects you should and should not staff for now). Those decisions require management to work for the good of the organization, not for themselves, and sometimes the organization prevents that with Management By Objectives, MBOs. The second reason is that some managers don't realize that people need to work on systems together to create a system that works.

What You Can Do
If you think your project is succumbing to too much work in process because of 100 percent utilization thinking, try creating a cumulative flow diagram. Measure your in-process and completion work over time. If you also track the growth of requirements, you can see if you will ever finish this project.

Without data, you might not be able explain the consequences of 100 percent utilization thinking. With data, you can start to explain bottlenecks and the issues of