Exploratory Development

Retrospective is one of the most ignorable practices from agile processes. Why people don’t use retrospective? Mostly they don’t see the value yet they see difficulties that it causes.

No doubt any practice which provides no value should be cancelled. But some practices provide long-term value which some people don’t take into consideration.

Some obvious goals of retrospective:

• Gather feedback
• Improve situation using gathered data

Unfortunately it is not so easy. Main problems are:

• Insincere atmosphere prevents useful and thorough feedback, in such team (or even entire organization) retrospective can transform into “witch hunting”.
• Team members don’t take into account long-term benefits of retrospective, they look only for short-term ones, and stop conducting retrospective very quickly (or even don’t start)
• Improperly organized retrospective without clear goals produces no real results, it’s a waste of time

There are several important hidden advantages which outweigh potential problems:

• Such meeting can make the atmosphere more open, because people get used to give and get feedback
• As soon as project team see that process can be tailored to them company-wide standards meet less resistance (although any standard which usefulness can’t be explained to a team will meet resistance)
• It can help to improve company-wide processes
• It helps to react to changes

This article doesn’t cover organization strategy in part of reflection and improvement. It is mostly about how to conduct useful retrospectives. It includes:

• Benefits from different point of views
• How to conduct
• Tools for retrospective
• Company-wide retrospective

Benefits from different point of views

At company level main benefits behind retrospective are:

• Get feedback
• Learn and improve
• Create open atmosphere
• Create proactive environment

From project manager’s point of view:

• Get feedback
• Tailor process to a project
• Create open atmosphere
• Create proactive environment

Team members’ point of view:

• Provide feedback
• Tailor process to their needs, remove overhead

How to conduct

Retrospective needs well-thought-out organization. There are 3 main areas:

• Preparation
• Meeting
• Action

Preparation

One of the most important parts here is to explain to team members and stakeholders why retrospective is so important and how it can help them.

Retrospective should have clear schedule. It is better to hold the meeting in a separate room – it helps to refresh thoughts and look “from outside” at what has been done and is going on.

Meeting

First of all, one person is needed to be a facilitator. It can be a team member, a Scrum Master, an outsider from other team or even professional facilitator. Facilitator may be changed from time to time.

Facilitator should explain in brief goals of this meeting, procedure and expected outcomes. Then s/he should set people in the right mood when they are ready to get feedback, analyze situation and think over solution. It’s a good practice to make every person say at least something at the beginning, although certainly it should not be in the form “say something”.

If it is not the first retrospective then results of the previous one should be reviewed – what has been completed, what is not, maybe some items are not relevant anymore.

Then it’s time for identification of working practices and ongoing problems. When problems and working practices have been identified people should come up with solution for problems. Often these 2 stages are merged into one. Timeframe should be taken into consideration – it should be possible to realize most of the planned actions within this timeframe.

As outcome it is a smart move to have: list of working practices, list of problems, and list of solutions in the form of action log.

Action

If retrospective leads to no action usually it is useless meeting. Action log helps to concentrate on real activities instead of just talking about problems.

Action log should be highly visible. For instance, action log printout can be hung on the wall in team’s room. As soon as any item is completed action log should be updated (e.g. cross out this item on the printout). Such visible progress makes people believe that retrospective is in fact useful tool.

Tools for retrospective

There are a lot of tools to make retrospective more productive. The following ones are reviewed below:

• What went well/What could be improved
• Keep this/Ongoing problems/Try this/
• Starfish
• Timeline

What went well/What could be improved

This is the simplest format of questions for retrospective. The first question, “What went well?” concentrates on practices which should be saved. The second one is used to figure out how work can be improved. Answers to the second question are mostly current problems, but wording highlights positive approach – if something can be improved then team should suggest how to improve it.

Keep this/Ongoing problems/Try this

Slightly more detailed questions. The first question is used to figure out what practices worked well, the second one concentrates on problems (but not on solutions), and the third one provides psychologically safe way to suggest ideas how to solve some problems (or just make work better).

Starfish

This set of questions is based on starfish diagram.

• Start doing – e.g. try to change something or introduce new practice
• Stop doing – e.g. cancel some useless practices
• Continue doing – it works well, it should be saved
• More – team should pay more attention (and time) to this
• Less – team should pay more attention (and time) to this

Timeline

Timeline is a tool which helps to build retrospective using facts. Timeline consists of area which represents whole sprint (left side is the beginning, and the right one is the end), and set of post-it notes with events. Events are placed according to their date (it is not required to place them exactly at specific date, approximate position is enough). Events may have different colors – according to their impact (positive, negative, neutral), component (process, code, tests, etc) or priority.

There are several approaches to building timeline: some people recommend populating it during sprint, some people recommend reconstructing timeline at the beginning of retrospective. The first one almost guarantees that all main events will be recorded, while the second one is simpler to use.

Using timeline it is quite easy to identify real problems.

Company-wide retrospective

Practice of reflection can be used outside project teams. It can be used at different levels, e.g. at level of project managers or sales managers.

To simplify information exchange between levels some retrospectives can include stakeholders from different levels (e.g. project team + division manager, or project managers + several developers + division manager + CEO). But in this case psychological aspect becomes even more important. If a team is at “performing” stage then team members can make such retrospectives useful, otherwise it is likely that no one mentions any serious problem. In case of multi-level retrospectives group can get too large, so that’s important to set and explain clear procedure.

Project-level retrospectives are not an easy task and retrospectives at other levels (especially multi-levels) are even more difficult. But it gives all-round frequent feedback, makes inter-level walls more transparent, helps to share common goals within organization.

It is a long-term tool

If a team/company doesn’t understand long-term benefits of retrospective it is likely that it gives up soon (or even worse – will conduct useless retrospectives thus making people consider any retrospective a waste of time). But if a company understands advantages of retrospective and can explain to its staff how it can help them, then retrospective becomes very useful tool.