Principle 7 can be used on every project, not just those that are as out of balance as the sample project. Every project has a bottleneck activity. Even when the bottleneck moves, Principle 7 applies to the new configuration of bottleneck and nonbottleneck activities.
Consequence 3. Applying the principle of expendable efficiency yields different methodologies in different situations, even keeping the other principles in place.
Here is a first story, to illustrate. Winifred and Principle 7.
Project Winifred did resemble the sample project above. It was the project on which I learned to apply the principle. In the middle of the project, there were about a dozen Smalltalk programmers, four COBOL programmers, and two DBAs. The Smalltalk programmers could revise their designs faster than any of the others. The two DBAs were overloaded, as in the example story. We arranged for the Smalltalkers to work very closely with the requirements writers, getting started as soon as there was information to work from. Applying osmotic and face-to-face communication, rather than documents between them, the Smalltalkers worked by word of mouth, changing their designs as they heard new information from the requirements writers.
The DBAs and COBOL programmers started their work only after the Smalltalkers had a "relatively stable" design that had passed its design review.
I described this use of the principle as the Gold Rush strategy in Surviving Object-Oriented Projects (Cockburn 1998). That book also describes the related use of the Holistic Diversity strategy and examines project Winifred more extensively.
Here is a second story, with a different outcome.
eBucks.com and Principle 7
The company eBucks.com had 15 developers and a dozen business specialists. They also had a backlog of six dozen work initiatives. The programmers were being distracted away from their work several times each day and consequently were making little headway against their backlog.
Gold Rush was exactly the wrong strategy to use in this situation. The programmers had no spare capacity. In fact, programming was the bottleneck activity.
We first took several steps to reduce the distractions hitting the programmers. That was still not enough, given their backlog.
We decided, therefore, that the business specialists would write use cases, business rules, and data descriptions to hand to the programmers.
Note that this strategy appears at first glance to go against a primary idea of this book: maximizing face-to-face communication. However, in this situation, these programmers could not keep information in their heads. They needed the information to reach them in a "sticky" form, so they could refer to it after the conversations.
After the programmers work through the backlog, the bottleneck activity will move, and the company may find it appropriate to move to a more concurrent, conversation-based approach.
Just what they do will depend on where the next bottleneck shows up.
Here is a third story. Udall and Principle 7
Project Udall had become stuck, with dozens of developers and a large, unworkable design. Four of the senior developers decided to ignore all the other developers and simply restarted their work. They added people to their private workgroup slowly, inviting only the best people to join them.
They reasoned (correctly, as it turns out) that the two bottleneck activities were getting political alignment on design decisions and transferring information from the senior designers' heads to the others.
They decided that it would be more effective for them to let the others do anything other than program on the system than to spend key design resources convincing and training the others.
This was a most surprising and effective application of the principle of expendable efficiency.
When I interviewed one of the team leads, I asked, "What about all those other people? What did they do?"
The team lead answered, "We let them do whatever they wanted to. Some did nothing, some did small projects to improve their technical skills. It didn't matter, because they wouldn't help the project more by doing anything else."
The restarted project did succeed. In fact, it became a heralded success at that company.
Consequences of the Principles
The above principles work together to help you choose an appropriate size for the team when given the problem, and to choose an appropriate size for the methodology when given the team. Look at some of the consequences of combining the principles:
Consequence 1. Adding people to a project is costly.
People who are supposed to know this sometimes seem unaware of it, so it is worth reviewing.
Imagine forty or fifty people working together. You create teams and add meetings, managers, and secretaries to orchestrate their work.
Although the managers and secretaries protect the programming productivity of the individual developers, their salaries add cost to the project. Also, adding these people adds communication needs, which call for additional methodology elements and overall lowered productivity for the group (Figure 4-19).
Figure 4-19. Reduced effectiveness with increasing communications needs (methodology size).
Consequence 2. Team size increases in large jumps.
The effects of adding people and adding methodology load combine, so that adding "a few" people is not as effective an approach as it might seem. Indeed, my experience hints that to double a group's output, one may need to almost square the number of people on the project! Here is a story to illustrate. Mythical Man-Month Revisited
Fred Brooks, in the Mythical Man-Month, writes that one may have a project that cannot be delivered in time by even the ten best people in the world. As a consequence, he writes, one may have to use 200 or 300 people.
He explains that there are two effects driving the need for extra people. One is that more people are needed to handle the communications load on the project. The other is that it will not be possible to hire 200 people of the same caliber as the proposed 10. The communications load is compounded by a decrease in talent.
Here is a second, more recent story, with a similar outcome.
Six to 24 Programmers
At the start of one fixed-priced project, we estimated that we could deliver the project with six good Smalltalk programmers. That wasn't an option, though. At that time, we couldn't get our hands on six good Smalltalk programmers. To make matters worse, we were given ten novices to train and only two expert programmers to both train them and create code.
During our estimation process, we concluded we would need a staff of 24 programmers of mixed abilities.
Over the course of the project, we eventually had four experts and 20 other programmers with mixed experience. We got our 24 programmers.
We reviewed our assessment at several times during the project, and at the end. Yes, six good Smalltalk programmers would have been sufficient. No, 12 programmers, even 16 programmers of the mixed experience levels we were seeing would not have been sufficient.
The correct jump was from 6 good programmers to 24 programmers of mixed ability.
Consequence 3. Teams should be improved, not enlarged
Here is a common problem: A manager has a ten-person team that sits close together and achieves high communication rates with little energy.
The manager needs to increase the team's output. He has two choices: add people or keep the team the same size and do something different within the team.
If he increases the team size from 10 to 15, the communications load, communications distances, training, meeting, and documentation needs go up. Most of the money spent on this new group will get spent on communications overhead, without producing more output.
This group is likely to grow again, to 20 people (which will add a heavier communications burden but will at least show improvement in output).
The second strategy, which seems less obvious, is to lock the team size at 10 people (the maximum that can be coordinated through casual coordination) and improve the people on the team.
To improve the individuals on the team, the manager can do any or all of the following: