Changing Software Development: Learning to Become Agile

8.9. When Not to Change

Of course every project is important – if it were not, we probably wouldn't bother doing it, and if we did we wouldn't be motivated. But if we're going to make changes, we have to allow some slack to take some risks.

Some projects are more risk averse than others. For example, critical-safety projects, such as the software for a nuclear reactor, need to avoid risk. Such projects will take a lower-risk approach than projects for less critical systems. Alistair Cockburn^[] calls this aspect system criticality. System criticality distinguishes between systems where failure cause discomfort, loss of discretionary money, loss of irreplaceable money and loss of life. Cockburn proposes a scale of escalating criticality, where failure becomes progressively more consequential (shown in Figure 8.8).

^[] See Cockburn (2002).

When deciding how much risk you can accept, it's important to consider the consequences of failure. All change involves an element of change, but so too does inaction. Not changing may make the current project safer, but may endanger the longer-term survival of the organization. When deciding how much change to accept, these risks need to be balanced.

If you can't accept any risk in the current project, then you'll have to find ways of learning and practising outside of the project. For example, airlines are highly risk averse and so they use flight simulators to train pilots and update them on airports and planes. This approach is expensive, since ...