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

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 100 percent utilization. And, with a little slack, you can increase your throughput and finish work.