How are Agile development practices affected by a pervasive system change?

Question

When a large system developed by Agile process requires a sudden large-scale change that affects most everything, what is the best way to go about it using Agile? Does the iterative part change at this point?

For example, what if a decision is made to make a centralized system a distributed one? Or choose another large pervasive example.

Arguably large changes should have been planned for, but it's never a perfect world which is one of the reasons Agile exists, so assume that suddenly a major change is introduced that shakes the foundation.

Edit to summarize solutions:

• It's incremental all the way no matter how large or small the change may be.

Answer 1

"Does the iterative part change at this point?"

Never.

No matter how "pervasive" the change appears to be, you still have to work incrementally, in iterations you can manage.

You still have to prioritize the changes and make them in a way that will continue to pass unit tests and can be released when needed.

You may, for example, find that fixing 80% of the system is sufficient, and you may release. Or may be required to fix 100% of the system before releasing.

You still work incrementally. In sprints. Irrespective of when you release.

Answer 2

Agile has no magic answers.

There's a number of approaches :-

Plot a path of reasonably incremental changes to change the system from one archtecture to another. If you have reasonably well factored code, you should be ditching the code that is made redundant by the change and keeping stuff thats independent of the change.

Another approach if things are really different, start a parallel development of components for the new system.

Or, start new and steal as much as you can from the old project.

Depends how BIG the change really is.