Changing Software Development: Learning to Become Agile

6.1. Change

It can seem odd when you first think about this, but change is a subject in its own right – albeit a slightly abstract one, but then software folks are used to dealing in abstractions. The introduction, management, consequences and failure of change are documented in many books and journals. Sometimes the only thing that all these commentators seem to agree on is that most change initiatives fail.

The hard truth seems to be that most deliberate attempts at change fail. The exact numbers vary, depending on whose work you read, but there's general agreement that most (perhaps as many as 70 %) change initiatives fail.^[] This is a sobering thought to anyone contemplating change.

^[] This particular percentage is taken from Beer and Nohria (2000).

One of the basic mistakes in creating change is to reduce the change to one of technical implementation. Issuing mandates to order changes overlooks the fact that change is more subtle and multi-facetted than issuing mandates. Mandates have their limits. We may be able to mandate the use of Java, but can we mandate that all programs are bug free – or that all projects will be delivered on time?

Just because we issue a rule doesn't mean it will be followed. There are rules against speeding on the highway in most countries, but people still do it. When we use mandates to bring about change, we ignore the subtleties, risks and realities involved with change.

Software developers, like many knowledge workers, are often authorities in ...