Accepting Change

Introduction

Agile methodologies allow you to accept change at a far greater frequency than Waterfall-based methodologies. However, this does not mean that you can accept constant changes throughout development without it having a detrimental affect on the team's ability to deliver. Most change will cost the project time and money, it will just cost you a lot less in Agile than in Waterfall.

Types of Change

You have to recognise that there are different levels of change:-

• Incremental




• First order change


• Ongoing


• Evolving


• Cumulative


• Continuous

• Radical




• Second order change


• Infrequent


• Discontinuous


• Intentional


• Episodic

These different levels of change can be plotted against how fundamental what you are changing is to the current development. Are you changing something that is core to the implementation (adding new data fields) or something peripheral (some static text).

Accepting Incremental Change

The quadrants illustrate the likely impact of different levels of change. This states that any incremental changes to non-core functionality can easily be accepted during development. So the requirements can evolve during a story, as long as the changes are incremental, cumulative and don’t fundamentally change the structure or direction of the development. These changes will typically come out of discussions between the developers, QAs and the Truth and be recorded as an additional acceptance test.

I see this situation as analogous to that of the die cutter in the Toyota Production System (TPS). The car designers broadly know what shape the body panel is going to be that the die will press. Therefore the die cutter can order the block of material and begin cutting before all the detail is known. As long as the car designers only make incremental and cumulative changes to the panel design, all the initial work will still be valid and nothing will have to be thrown away. However, if they make a fundamental, core change to the shape of the panel, the block of material will have to be thrown away, and the cost of materials, labour and delivery date will be high.

Reacting to Radical Change

If there is a radical change to something core to the implementation, then this will cause a high disturbance and risk to the story under development. These sort of changes are where the Truth says to the developers, mid-story: "I've got a change of context – we actually want it to do this now." Or an interaction designer says "I've changed the page to work like this".

The question is: how do you proceed at this point? You could try and be flexible and change the direction of the implementation and take a bit longer than estimated. However, from experience this approach is damaging to the project. I think that at this point, you have to either stop work on the story and back it out (stop the production line) or continue with the previous requirements until the story is completed and all the acceptance tests are done. The latter option is particularly demoralizing for developers and QAs, spending days writing and acceptance testing something that is going to be ditched. I would therefore favour the former approach – back everything out, delete the code, record the tasks and storypoints that were completed and start with a new story. It seems drastic – particularly if the new requirements aren't completely different, but its usually quicker and cleaner to start again anyway.

Making a Call on Marginal Change

If you get any changes to the Core functionality mid-story, it should probably be rejected at least until you’ve backed out or completed the story in question.
If you get any changes to Peripheral functionality, it's a closer call. If it's a complete (ie Radical) change to the peripheral functionality, then it should be rejected until later in the iteration. Anything less, then look at the impact and make the call – break it out if at all possible, try not to absorb it in the current tasks and estimates.