Whole Agile Teams: Beyond Resource Efficiency

When software organizations grow to a certain size, they tend to run into a staffing problem.

Teams are organized functionally, with a team of analysts, a team of testers, a team of programmers for the web, another programming team for the data warehouse, and so on. Someone in the project management organization, or PMO, has a very large spreadsheet with every person’s skills listed. Staffing a project means lining up a programmer with JavaScript and CSS, a programmer with back-end Java, an analyst, a web-based tester, and so on, on a certain date. The team stays together until the project ends, and then everyone is released to other projects.

Every time I run into a client like this, I get a little uncomfortable because it reminds me far too much of what I did in the previous decade. Yes, the companies I worked for might have had stories, stand-up meetings, and sprints, and even retrospectives—but the “teams” were project teams. Worse, the projects would ramp up and down. As a programmer, I would probably work on three projects at a time; one in requirements, another in code, and a third in test. Plus, there was always production support.

That doesn’t sound very agile, does it?

The authors of the Agile Manifesto tend to suggest something else: creating long-term, sustained, whole teams that have all the skills they need to take the software from inception to production.

The downside of that ideal is the loss of efficiency; the skills of the database administrator or graphic designer might not be needed at all on this project. They could be better put to use on some other project, so the PMO gets out the spreadsheet.

To be fair, when my customers say they don’t subscribe to every piece of agile dogma, I am very sympathetic. They are just trying to be efficient. Who could oppose the pursuit of efficiency?

And yes, being 100 percent busy is a certain kind of efficiency—an efficiency of resource. But there is more to being effective than the pursuit of 100 percent busyness all the time. Sometimes a little extra availability in your schedule to be able to respond to change more quickly can improve outcomes more than “staying busy.” One term for that is flow efficiency, and while the Agile Manifesto implies the difference, it does not spell it out.

Luckily, there is a little thing called data that can come to our aid.

Consequences of Resource Efficiency

When I was working on three or four projects at a time, the problem was the feedback loop was too slow. The system had wait states in it; I would complete a deliverable, say, some code, and wait for someone else to do their part. Because of the delays, we loaded up the work in progress, adding a few more projects in the mix.

Except, of course, the reason for the delays was also due to multitasking. When I finished a deliverable, the person next in line couldn't look at it because he was busy doing something else. And then when the tester found problems, she had to wait for me to respond because I would be busy with something else. Multitasking caused delays, which were “fixed” by more multitasking, which caused more delays, in a vicious cycle.

What happened next is predictable: The time it took to get anything doneexploded. When I was working four projects, the best case was that it would take four times the usual time period to finish them. We call that time period from start to done cycle time, and the 4x explosion does not include waits created by multitasking. In his book Why Limit WIP: We Are Drowning in Work, Jim Benson includes an exercise for the reader to simulate multitasking: Start counting from one to a thousand for a minute, and then alternate between the numbers and saying the alphabet. You’ll find your efficiency goes down by much more than half.

As cycle time goes (way) up, the amount of delivered software goes down.

When our customers figured out that a typical project ran six to nine months, two things happened. First they tried to get in everything on the project, including the kitchen sink, because next time the PMO might choose to fund some other department. Second, they tried to sneak in projects in other ways—maintenance requests, bug fixes, emergencies, or even straight-up side deals with line managers. This created the appearance of getting something done, but not the reality. Cycle time went up more, and performance went down more. The subtitle of Benson’s book, “We are drowning in work,” became our motto.

My story is not unique. In his book Joy, Inc.: How We Built a Workplace People Love, Richard Sheridan tells essentially the same story of his time at Interface Systems, with hidden work and multitasking destroying his ability to predict when anything would get finished. This is Lean: Resolving the Efficiency Paradox, by Niklas Modig, compares a resource-efficient health care system that diagnoses cancer over a period of weeks with a flow-efficient one that does full diagnosis and begins treatment the same day.

The Whole-Team Effect

Obviously the relentless pursuit of efficiency is not the answer; it is the problem! People don’t need to be busy all the time. Instead, the software needs to keep moving forward. If you have a multidisciplinary team and there is no need for the database admin or graphic designer for the next project, they can pair (or mob) and learn the job from someone else, resulting in more multiskilled team members. That way, if the project hits a bottleneck in testing, the graphic designer–turned–part-time tester will be able to contribute.

This idea that we need to get beyond “I do my job, you do yours” and instead focus on what the software needs to move forward is sometimes called the whole-team effect.

And, yes, all of these things are agile. The problem is they are hard, and most organizations choose to implement only the easy bits … and cycle time keeps exploding, and value delivered goes down.

If you find yourself in this boat, remember that you have a choice to make: resource efficiency or flow efficiency.