Measure Throughput, Not Utilization

Keeping your team busy with work all of the time may seem good for productivity and a good use of your work force. But it comes with serious backlash in the form of delayed work, incomplete iterations, technical debt, and the negative consequences of multitask context switching. In this column, Johanna Rothman explains how teams should focus on throughput and not the conceived benefit of 100 percent utilization.

Many managers think that 100 percent utilization of people is a desirable state. "If we keep people busy, we'll get more work out." One hundred percent utilization might work for piece work or time-based work, but in knowledge work, utilization doesn't work that way. Once you get past about 80 percent utilization, you get less done, because there is no slack for people to take up the work that arises or to think about how to do their work better. You also incur technical debt and the costs of multitask context switching. That's because project work is just one of the kinds of work we do.

Work Is More Than Project Work
In addition to project work, we also have: time-based work, such as periodic work-those monthly reports or yearly budgets or training or vacation; ongoing work, such as support for the operation of an organization or department; and in-process, ad hoc work—those emergency projects, work you are doing as the result of crises or other surprises. And, let's not forget our management work.

If you ask people to work 100 percent on project work, they cannot help but neglect the time-based work, especially the ongoing or ad hoc work. But, people have consciences, so they postpone project work to take care of emergencies. They will ignore any management or strategic work because the urgent work takes precedence over important work.

The problem is that the ongoing or ad hoc work is urgent and keeps the organization going. For example, fixing customer-discovered defects keeps the customers happy and keeps senior management happy because they are not hearing about problems. But, the important work, such as discovering how the defects arose or how to automatically find them, allows the organization to change how people work or what people do, in order to increase everyone's capacity.

You certainly want to achieve zero ad hoc work in an organization where projects provide the means to continue the organization's work, and I don't know a single organization that has accomplished that goal. You somehow have to finish enough of the urgent work so you can achieve the important work. If everyone is 100 percent allocated to projects, they cannot think about anything else.

Slack Enables Throughput
Even if you have no ad hoc or ongoing work, keeping people 100 percent busy guarantees their throughput will decrease.

Here's an example: An organization new to agile has four product owners and two project teams. Each product owner is pushing his work on each team. That means each team is contending with two product owners and their backlogs. Each product owner wants his work complete in any given iteration. Because of the pressure, developers start signing up independently for stories, not planning and estimating an iteration as a team. As one product owner said, "I can make sure my developers are busy every minute of every day."

The developers attempt to "finish" their development work in the two-week iterations. After the first iteration, the testers realize they cannot complete their testing inside the two-week iteration, so the product owners demand the testers test in the following iteration. The developers think this is OK, and the testers reluctantly agree.

After the second two-week iteration, the developers mark their stories as complete. But, because the testers have not yet finished testing the work from the first iteration, nothing is actually marked as done. And, the testers have interrupted the developers with questions.

After the third iteration, still nothing is marked done. The developers are not helping with hooks into the code for tests, because they are "too busy" trying 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

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.