PRINCE2 Agile 2016
Previous Section   Next Section

19.4 Agile concepts and techniques

19.4.1 Retrospectives

The retrospective is a very common technique and is used regularly when working in an agile way. It involves looking back and reflecting on how things went in terms of how a team worked, in order to make improvements to how they work going forward. A retrospective is a type of review that specifically looks at the way of working as opposed to looking at what was produced (e.g. sprint review).


Retrospectives include or are similar to continual improvement, Kaizen, inspect and adapt. The basics

The role of retrospectives is extremely important. It could be said that this is as significant as any concept, technique or behaviour in agile. It is central to learning lessons and can be part of any continual improvement process. Therefore, not only do retrospectives need to be carried out, but they need to be carried out well.

The most important point to understand about retrospectives, and running them well, is that they must be planned, structured and facilitated. If they are run as an unstructured meeting, they can become ineffective and they may also become a chore. How to run a retrospective is decided by the team, so it may become quite informal; however this does not imply any lack of structure.


PRINCE2 uses the term ‘review’ for a specific purpose (i.e. when using the quality review technique) whereas it is used frequently in many forms when using agile.

Not only do retrospectives need to be planned, but they also need to be adapted to keep the participants stimulated. Retrospectives are only as good as the contributions made by the people who take part. Further information

The first step in all PRINCE2 processes is to take the learnings from previous projects or stages. A retrospective can last any length of time but it is usually proportionate to the duration of activity that is being reviewed. A retrospective for a 2-week sprint may take 2 hours, whereas a retrospective of a 6-month project may take a whole day. In effect a retrospective is a mini-workshop. Section 26.4.1 describes how powerful workshops can be; all of the tools, techniques and considerations involved in workshops can also be used by retrospectives. Examples would be the choice of tool or technique, how to manage conflict, laying out the room, etc.

A lot of guidance exists on how to run a retrospective and it closely aligns with how to run or facilitate a workshop. Section 26.4.1 refers to the five preparation steps needed to run a successful workshop and the same steps apply to a retrospective. There are many suggested formats and many tools and techniques available. A retrospective would have a similar structure to the following:

  • Objective This could be very specific to a certain area or more broadly based.
  • Attendees Usually this would just be the team and all of them should be present.
  • Agenda This would need to be adjusted to suit the situation (see section
  • Logistics These would be the same as for any workshop (e.g. layout, materials, refreshments).
  • Pre-reading Distributing key information and results in advance could result in a faster start to the retrospective and therefore it would take less time. Agenda

Many techniques exist to capture lessons (or ‘learnings’) but typically a retrospective will involve an agenda with the following steps in some form:

  • agreeing the objective, agenda and any house rules
  • reflecting on what has happened in terms of actual results and measures (e.g. 42 story points were delivered, 7 defects were found)
  • generating views on what went well and what did not go so well
  • actions on what to do next time, who is responsible for each one and when they are due to be completed
  • close. Hints that may prove useful

Including someone from project support in a retrospective could be useful to capture the lessons in order to transfer the learnings across projects and the organization as a whole. The team would need to be comfortable with this, as they may prefer to pass on their findings after the retrospective.

Occasionally, key documents and artefacts could be specifically reviewed (e.g. the definition of ‘done’ or working agreements).

Figure 19.2 A Glad! Sad! Mad! board

Figure 19.2 A Glad! Sad! Mad! board

Definition: Glad! Sad! Mad!

This is a feedback technique that can be used by a team in a retrospective. Each team member writes one or more sticky notes and puts them into the appropriate column. This lets everyone else know what made them ‘glad’ during the last timebox, what made them ‘sad’ and what even made them ‘mad’(see Figure 19.2)!

It is often a good idea to ensure that only a few changes to the process are suggested at each retrospective, as opposed to working on too many improvements at the same time. In other words it is better to produce two actions from a retrospective that are actioned, because the work involved is easy for the team to take on, as opposed to ten actions which can psychologically seem like too much extra work for a team, and therefore not worth starting. Feedback can be prioritized using a simple classification system of ‘high, medium and low’ or by plotting the feedback on an impact/effort grid (which contains two axes that show the effect of the change and the amount of work involved in it).

A final step in a retrospective could be to reflect on how well the retrospective process worked. Put another way it would be a retrospective retrospective! Even if a team has become very good at doing retrospectives in a certain way, it can be worth introducing new techniques to keep people’s creativity fresh (e.g. Glad! Sad! Mad!).

Introducing an independent facilitator can be very effective. If the group does not choose this option then the person leading the retrospective should still be facilitative.

To introduce some variety to retrospectives it may be worth using some of them to look for improvements on specific areas of the process, whereas other retrospectives may have no specific area of focus.

Involving the people who use the process in improving the process ensures that there is buy-in to any changes, and that any change is permanent.

Kanban would refer to retrospectives as service delivery reviews at a team level, and operations reviews at a higher level, but they can be run in the same style or similar.

During a retrospective, feedback usually comes in two forms: facts and feelings. Sometimes it is beneficial to separate feedback when it covers both of these (e.g. having separate steps in the agenda). Facts are usually objective and measurable, such as ‘the customer was not available during week two’. Feelings are usually subjective and harder to quantify, such as ‘I felt let down by the release team as they promised me they would be ready’. It is the latter that is more likely to cause emotional responses and possibly conflict during a retrospective. Learn gradually

Identifying lessons and learning from them are two different matters. This is why a retrospective needs to carefully draw out the learnings from a group, analyse them and then distil them into decisions and actions that ensure the continual improvement of the process and the way the team works. This can then be recorded in the lessons log.

The best way to improve how a team works is little by little, and little and often. This applies to a sprint, a release, a stage or the whole project.

Previous Section   Next Section