The mechanism of change in agile approaches

"Evolution" and "revolution" describe 2 mechanisms of change:

1. Revolution: sweep away and replace
2. Evolution: copy; differentiate; select; amplify; repeat

This defines the difference between evolution and revolution - not the size of the change, or even the size of the steps in that change. It's the mechanism of change that is significant, because evolution (surprisingly to most people) can sometimes produce large changes in short periods, while revolution sometimes involves quite small changes.

Perhaps a discussion for another time is how this relates to politics and management, and why it is that many politicians/managers (even conservative ones) favour revolutionary changes - that they can take credit for? - over evolutionary changes, which necessarily require competition between ideas and failure of quite good ones, so that better ideas are amplified.

The mechanism of evolutionary change can be seen again and again in agile methods. I''ve written elsewhere about its relevance to the evolution of processes in Kanban (see "Evolution and the culture of an adaptive organisation"). Here's another example from a test driven process: the "test-change-test-change-test" cycle in BDD and TDD-like approaches.

A Test-Driven cycle in agile development

The point about this process is that it must start and end at "survivable" points, where specs, tests and model (i.e. code) agree. There are many cases where tests or metrics fail the quality test (a "red-bar" or failed build results) and these cases must either be changed again or reverted. There are also many points where change can be introduced: the model, the requirements or the tests of fitness, but every change is subject to the selection criteria which eliminates the unfit and amplifies (promotes to "head" - where it is again copied and modified) the instance with improvements.

This is not like evolution. It is evolution.