PRINCE2 Agile 2016
Previous Section   Next Section

14.2 The general view of agile with respect to the Change theme

Agile embraces change. One of the four values of the Agile Manifesto is about ‘responding to change’ and one of its principles is ‘welcoming changing requirements, even late in development’.

Agile sees change as inevitable and a normal situation. The understanding of a project will change as the project proceeds: ‘unknowns’ will surface and unexpected events will happen. Responding positively to change when it happens results in a more accurate product being delivered, and because agile puts a lot of emphasis on flexing what is being delivered, this is where most of the change is managed and is the focus of PRINCE2 Agile.

14.2.1 Changes to what is being delivered

Changes to the detailed understanding of the product being created would typically be viewed in a positive light, as this greater understanding improves what is being produced. However, if the changes mean that the baseline upon which the work was justified is being compromised, then this may not be seen in a positive light, as it may be a symptom of significant misunderstandings from earlier on in the project.

One caveat to the idea of baseline change perhaps being unwelcome is that in a wider context it may be positive news – in the sense that it results in the fast failure of the project that would ultimately have delivered an unsuccessful outcome. This could represent good news in general, but perhaps not good news for that particular project.

In simple terms these different types of change to what is being delivered can be described as detail or baseline changes (see Figure 14.1).

Figure 14.1 Requirements change can happen to the baseline or to the detail

Figure 14.1 Requirements change can happen to the baseline or to the detail

14.2.2 Other types of change

Agile usually refers to change as something that affects a project’s products. PRINCE2 sees anything that affects the agreed baseline as change and handles it accordingly. If a team member becomes ill and will be unavailable for 2 weeks, then this would be handled as a change in the form of an issue as it will impact planning. A typical agile response to this (assuming the team was of sufficient size) would be for the delivery team to re-organize and aim to deliver less due to the reduced capacity, although this would depend on the level of collaboration with the customer.

Previous Section   Next Section