Alistair Cockburn - Agile Software Development

One could ask other questions to derive other, related principles. For example, it might be interesting to uncover a principle to answer this question: "How do forms of communication affect a sponsor's evaluation of a team's conformance to a contract?" This question would introduce the issue of visibility in a methodology. It should produce a very different result, probably one emphasizing written documents.

Principle 2. Excess methodology weight is costly.

Imagine six people working in a room with osmotic communication, drawing on the printing whiteboard. Their communication is efficient, the bureaucratic load low. Most of their time is spent developing software, the usage manual, and any other documentation artifacts needed with the end product.

What size problem can a given number of people attack, using various methodology weights?

Problem size

Many people using a heavier methodology

Many people using a very heavy methodology

Many people using a light methodology

Methodology Weight

Figure 4-17. Effect of adding methodology weight to a large team.

Now ask them to maintain additional intermediate work products, written plans, GANTT charts, requirements documents, analysis documents, design documents, and test plans. In the imagined situation, they are not truly needed by the team for the development. They take time away from development.

Productivity under those conditions decreases. As you add elements to the methodology, you add more things for the team to do, which pulls them away from the meat of software development.

What size problem can a given number of people attack, using various methodology weights?

Problem size a few people using a light methodology a few people using a heavy methodology.

Methodology Weight

Figure 4-18. Effect of adding methodology weight to a small team.

In other words, a small team can succeed with a larger problem by using a lighter methodology (Figure 4-18).

Methodology elements add up faster than people expect. A process designer or manager requests a new review or piece of paperwork that should "only take a half hour from time to time." Put a few of these together, and suddenly the designers lose an additional 15-20% of their already cramped week. The additional work items disrupt design flow. Very soon, the designers are trying to get their design thinking done in one- or two-hour blocks which, as you saw earlier, does not work well.

This is something I often see on projects: designers unable to get the necessary quiet time to do their work because of the burden of paperwork and the high rate of distractions.

This principle contains a catch, though.

If you try to increase productivity by removing more and more methodology elements, you eventually remove those that address code quality. At some point the strategy backfires, and the team spends more time repairing bad work than making progress.

The key word, of course, is excess. Different methodology authors produce different advice as to where "excess" methodology begins. Based on the strengths of people we have discussed so far—being communicating beings and being good citizens—I find that a project can do with a lot less methodology than most managers expect. Jim Highsmith is more explicit about this. His suggestion would be that you start lighter than you think will possibly work!

There are two points to draw from this discussion:

· Adding a "small" amount of bureaucratic burden to a project adds a large cost.

· Some part of the methodology should address the quality of the output.

Principle 3. Larger teams need heavier methodologies.

With only four or six people on the team, it is practical to put them together in a room with printing whiteboards and allow the convection currents of information to bind the ongoing conversation in their cooperative game of invention and communication. After the team size exceeds 8 or 12 people, though, that strategy ceases to be so effective. As it reaches 30-40 people, the team will occupy a floor. At 80 or 100 people, the team will be spread out on multiple floors, in multiple buildings, or in multiple cities.

With each increase in size, it becomes harder for people to know what others are doing and how not to overlap, duplicate, or interfere with each other's work. As the team size increases, so does the need for some form of coordination and communication.

Figure 4-17 shows the effect of adding methodology to a large team. With very light methodologies, they work without coordination. As they start to coordinate their work, they become more effective (this is the left half of the curve). Eventually, for any size group, diminishing returns set in and they start to spend more time on the bureaucracy than on developing the system (the right half of the curve).

Principle 2 describes the left half of the curve: "Larger teams need heavier methodologies." The right half of the curve is described in Principle 3, "Excess methodology weight is costly."

Principle 4. Greater ceremony is appropriate for projects with greater criticality.

This principle addresses ceremony and tolerance, as discussed in the second section of this chapter. A Portfolio of Projects

In the IT department of the Central Bank of Norway, we worked on many kinds of projects.

One was to allow people to order dinners from the cafeteria when they worked late.

One was to provide SQL programming support for staff who were investigating financialinvestments.

A third was to track all the bank-to-bank transactions in the country. A fourth was to convert the entire NB system to be Year-2000 safe.

The cost of leaving a fault in the third and fourth systems was quite different from the cost of leaving a fault in the first two. I use the word criticality for this distinction. It was more critical to get the work correct in the latter two than in the former two projects.

Just as communications load affects the appropriate choice of methodology, so does criticality. I have chosen to divide criticality into four categories, according to the loss caused by a defect showing up in operation:

· Loss of comfort. The cafeteria produces lasagne instead of a pizza.

At the worst, the person eats from the vending machine.

· Loss of discretionary moneys. Invoicing systems typically fall into this category.

If a phone company sends out a billing mistake, the customer phones in and has the bill adjusted.

Many project managers would like to pretend that their project causes more damage than this, but in fact, most systems have good human backup procedures, and mistakes are generally fixed with a phone call. I was surprised to discover that the bank-to-bank transaction tracking system actually fit into this category. Although the numbers involved seemed large to me, they were the sorts of numbers that the banks dealt in all the time, and they had human backup mechanisms to repair computer mistakes.

· Loss of essential moneys.

Your company goes bankrupt because of certain errors in the program. At this level of criticality, it is no longer possible to patch up the mistake with a simple phone call.

Very few projects really operate at this level. I was recently surprised to discover two.

One was a system that offered financial transactions over the Web. Each transaction could be repaired by phone, but there were 50,000 subscribers, estimated to become 200,000 in the following year, and a growing set of services being offered. The call-in rate was going to increase by leaps and bounds. The time cost of repairing mistakes already fully consumed the time of one business expert who should have been working on other things and took up almost half of another business expert's time. This company decided that it simply could not keep working as though mistakes were easily repaired.