What is a good Retrospective?

In my master thesis I want to find out how “effective” retrospectives are – and what is the essence of a “good” retrospective.

So, before starting out, I need to define what I mean by "effective" retrospectives - and what I mean by "good" retrospective. And the criteria I want to measure this by.

Adherence to definition

The obvious answer to the definition of a good retrospective is based on its definition - i.e. does the inspected retrospective adhere to the definition.

Definition: Meeting where team members reflect on the past sprint (development process and practices) and identify improvements to make it more effective and enjoyable.

So the question becomes: To what extent was the retrospective comprised of the following two components?: 

  • reflecting on and identifing items/areas that went well and items/areas with room for improvement with regards to people, relationships, process, tools
  • creating a plan for implementing improvements in the way the team does its work

But just reflecting on the basic definition seems too little.

One can maybe glean the information whether or not the inspected meeting can be "defined" as a retrospective. One can identify whether the focus was lost. One can inspect whether there was a focus on a specific aspect (say tools), above the others. One can ask whether or not the plan was actually implementable. Even if one concentrates on the question of how well the two components were adhered to, this falls short of answering the question whether the retrospective was actually "good".

Adherence to goals of the retrospective

A retrospective is not an end in itself, but a means to an end.   Since a retrospective is a tool, good and effective need to be defined in reference to the "end".

In my literature research I have collected these 6 goals for retrospectives:

  1. continued improvement of the process (learn from mistakes) – not only during retrospectives
  2. team building, heart of team, trust, pragmatic, common values
  3. common focus on important things, real problems
  4. communication, handle issues, surface obstacles
  5. appreciation, motivation, honouring heroes, significant events, accomplishments
  6. common understanding measure and understand what we are doing – one person does not know whole story

Adherence to goals of software development

But even this does not seem to go deep enough. Take for example the first goal "improve process". Again: the process is not a means in itself. Improving needs to be defined according to the goals. Improving obviously means something needs to actually change because of the retrospective. But who decides whether something is an improvement?

Retrospectives intend to improve process. But the process is also not a means in itself --> a software team has the goal of delivering software on time, in scope, in good quality and in budget - not only in the short run, but in the long run. So retrospectives should increase success of project but also the soft team factors (that help the team work in the long run)

improving the software process has the goal of software project success. A lot of work has been done on identifying different factors relevant to the success of software projects. One question might be to what extent retrospectives influence these factors. 

Time Factor

Another obvious distinction when thinking about good retrospecitves is to inspect a) the actual meeting and b) what happens after the meeting..