Alistair Cockburn - Agile Software Development

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:

· Send them to courses to improve their skills.

· Seat them closer together to reduce communications cost.

· Improve their amicability and teamwork.

· Replace some of the people on the team with more talented (and more highly paid) people.

Repeating the strategy over time, the manager will keep finding better and better people who work better and better together.

Notice that in the second scenario, the communications load stays the same, while the team becomes more productive. The organization can afford to pay the people more for their increased contribution. It can, in fact, afford to double their salaries, considering that these 10 are replacing 20! This makes sense. If the pay is good, bureaucratic burden is low, and team members are proud of their output, they will enjoy the place and stay, which is exactly what the organization wants them to do.