Change

The way Agile methods handle change is probably the main differentiating factor for most people. The important point is to understand that the difference is a consequence of the lifecycle, rather than a direct approach: Agile methods are not dependent on upfront design and plan, and let the product evolve based on the feedback; so, any “change request” is just another input for planning the next iteration, without many consequences. There’s no upfront design you need to revise because of a change, and if the previous features were developed properly (independent of each other), not much rework is required either.

Change in Predictive Environments vs. Adaptive Ones

Change is inevitable, in any project. Change is not bad; only uncontrolled change is dangerous. A properly managed change in any environment results in a better product, and higher customer satisfaction.

Changes have fewer consequences in Agile environments, and that makes the change control much easier. The rest is the same for Agile and predictive methods.

PRINCE2 Agile Approach to Change

There are two types of change requests:

• Change requests that directly affect the baselines: They should be managed by the normal PRINCE2 change procedure, where the consequences are assessed, options are evaluated, the best option selected, and finally, applied to the baselines.
• Change requests that do not affect the baselines directly: They will be handled informally, by the development team, for example, the same way it’s handled in Scrum.

Based on this, it’s required to keep the baselines high-level enough to enable the Agile type of change management and adaptation.

Multiple small changes that are supposed to be handled informally by the development team can result in a major deviation in the baselines. Such deviations should be measured using the Progress theme, and may result in an exception. For example, a number of small changes might cause the project to become unable to deliver the MVP in the proper time; this would be an exception raised because of the scope and/or time targets move outside the tolerances.

Configuration Management

One of the main purposes of having a configuration management system is to help us assess the consequences of change requests. We need this information when the change request is major, and affects the directly. So, PRINCE2 Agile recommends keeping the Configuration Item Record high-level to allow for small, informal changes, and this should be reflected in the Configuration Management Strategy.

See Also

• Requirements focus area

External Links

• Chang theme in PRINCE2 wiki

Written by Nader K. Rad

This is (and will be) a work in progress: More details will be added in the future, depending on the feedback.

This wiki is developed and managed by an accredited trainer, independent of AXELOS. While aligned with their guidelines, it’s not an official resource.