Retrospective: how and why to conduct it?

Holding retrospectives is an activity that each agile team spends in order to solve their problems. What is a retrospective? This is a regular meeting in which the team discusses its workflow and changes something in it.

Why do I need a retrospective?

This is not an idle question, it is often asked by superiors when they are offered a retrospective. They ask: “Why? We can solve everything ourselves. ” Why is it impossible to make some boss or expert come, look and say what the team needs to do and what should be changed in the working process?
')
There are two main reasons. First, if we come to a team with ready-made solutions, a phenomenon arises that is called “ not invented here ”. Even if team members understand that this is the right decision and needs to be implemented, they do not have a sense of ownership towards it. Such solutions, not “earned” by the team itself, but “imposed” or proposed from above, are less likely to be implemented.

Secondly, software development is now so complicated and confusing that there is hardly a specialist who can, without knowing the context, describe how the processes in a particular team should actually work when solving a specific task. To find out, you need to try something, conduct experiments, look at what these or other decisions lead to. Only having tried, it is possible to understand, good or not very one or another practice in the context of this command.

However, there are things like good practice or best practice. These are practices that many use and which many help. Take, for example, code review: is it good practice or bad? It helps one teams. Others try to use it, and nothing good comes of it. This is because this particular practice is not good and not bad as such: it can be assessed only in the context of a specific team and situation.

At least, therefore, it is impossible to say in advance whether it will give some advantage or not. Code review is one example. In fact, this effect is characteristic of any practice - you can never know in advance how effective it will be in a given situation.

Goals and Results

The basis of the retrospective is the concept of the Deming cycle , PDCA (eng. Plan-Do-Check-Act). The purpose of the retrospective is to get a plan of changes by its end. But it is important to understand that this is not a plan for the final changes in the process - this is an experiment plan for the near term. We try something, and then we look at what came of it, and on the basis of this we make a decision.

Deming cycle: Plan - plan, Do - complete, Check - see what happened, Act - make some further decisions, decide what to do next. The retrospective must pass through this cycle. Actually, the retrospective itself is the Plan stage.

A retrospective, like any team meeting, must have some kind of goal. The purpose of the retrospective is to get a plan for a process experiment. However, many teams do not understand this. For example, in retrospect, teams sometimes try to come up with some global solutions to their problem, and run into the fact that they are unable to do this. They get stuck and end up doing nothing at all. If a team encounters such a problem, it is necessary to explain to it that it is necessary to move in small steps, trying different things and checking what comes out of it.

If a team simply believes that a retrospective is a meeting in order to discuss their work process and somehow improve it, then, as a rule, it all comes down to the fact that people come, talk about something, pour out their pain, make it easier soul - in the end it does not lead to anything. This is because the goal is not achieved, the plan is not received.



The task of the leader is to lead the team in the retrospective process to a specific plan. A plan is one of two things: either an action or a new arrangement. All that the retrospective boils down to is a list of the actions to be performed and the agreements that must now be followed.

What are actions? These are specific tasks with famous performers. Moreover, if the action is performed by someone who is not in the room right now, a person is selected from those present who take the responsibility to explain to the absent person what to do and how to do it, as well as to control the result. In the end, for each action is responsible someone from those present at the retrospective.

What are the retrospectives?

In general, it is reasonable to subdivide retrospectives into several types:

• retrospective in the most general sense of the word;
• quality retrospective;
• retrospective on issues;
• retrospective on any particular issue.

The retrospective is generally aimed, in the broadest sense, at understanding what is happening in the team, what problems it has and what can be done about it. It is sometimes called a psychotherapeutic retrospective. It usually begins with the question: "What problems do you see?"

Retrospective quality is usually reduced to the fact that it discusses either recent incidents or defects. The retrospective is devoted to discussing these defects and analyzing why they have arisen, that is, constructing a diagram of the root causes of defects. Anyway, in this case, the work is conducted with specific quality problems.

There are retrospectives on which work is carried out with problems arising from the customer or the owner of the product. This is the third type of retrospective. The fourth type is when there is a specific specific problem, and the retrospective is dedicated to its solution.

What is the problem?

What dysfunctions can arise in the course of retrospectives, and how to deal with them? Here is one of the dysfunctions: the team believes that it has no problems, its workflow is good enough, and does not see the point in improving it. As a rule, it is not. But the team just does not explain.

In order to move the team from this position, it is useful to invite to a retrospective of someone from the stakeholders - the customer or users who know that not everything is in order with the team (customers are generally very rarely completely satisfied with the team’s work). They can be satisfied to a certain extent, but, as a rule, they still have some thoughts on the subject of "what the team could have done better." If such a customer comes to the retrospective and tells it to the team, she has nowhere to retreat, she begins to discuss areas for further growth.

Another dysfunction is when, in retrospect, it is mostly someone one or two or three people who speak, and all the others sit and are silent. In fact, these people have something to say. Simply, if the team leader takes all the attention to himself, for example, he begins to dominate, and the rest just listen.

Why is that bad? If everyone openly expresses his thoughts, then the probability of finding the best solutions will increase significantly. When we participate in a group discussion, we encourage each other. This helps to come up with a better solution.

Often, the presenter (facilitator) of the retrospective helps to cope with this problem, so that each of those present will express his point of view. Sometimes in order to make retrospective participants more freely express their opinions, it is useful to give them the opportunity not to express their thoughts out loud, but to write them down on sticky sheets (they are usually attached to a wall or a special board, and this can be done both by the participants themselves and by for more “anonymity” - the facilitator).

Retrospective format: our offers

The literature describes various retrospective formats from simple to extremely specific. In one of the materials in our blog, we offered our own version: its distinctive features are simplicity and efficiency. Basically this is exactly what is required from such events.

Instead of setting up tight timing and sequence of actions, we suggest simply drawing the board into 4 main areas and filling it in during the discussion:

• Pros. What went well in the last iteration?
• Minuses. What problems were in the last iteration?
• Ideas. What ideas emerged in the course of retrospectives?
• Plan. What improvements are we planning for the next iteration?

Since the main task of the retrospective is to create a plan, all actions and intermediate stages serve only as a means to achieve the goal. First, each participant is given the opportunity to speak about the pros and cons of the last iteration. The pros and cons do not come about on their own - the basis for them is the plan drawn up at the previous retrospective, and the team itself decides where to place this or that point of the plan: whether it was completed (success) or not (failure).



As a rule, new ideas are born in the process of discussing the minuses of the last iteration, but they are not limited to them: this format of the retrospective does not prevent free discussion. At the same time, the facilitator or scrum master must ensure that the discussion does not turn into a search for the guilty: to achieve the goal, it’s not so much “who's to blame” but “what to do next”. Disputes about one or another idea at this stage are also useless: the plan will still get only those ideas with which all participants of the retrospective agree.

After discussing the pros, cons, and ideas, the team proceeds to drawing up a plan, which includes not just the results of the discussion, but (as already noted) concrete actions (“Run ...”, “Discuss ...”, “Generate ...”) or rules (“Task X to perform using approach Y "). At the same time, it is not worth trying to work out ways to solve all possible team problems - a plan of 3-6 points is enough for effective work at the next iteration. A plan that is too voluminous can ultimately prove to be impossible to fulfill and only demotivates the team.

It is worth noting again that the formats of the retrospectives may be different. One thing is important: retrospectives are not a single event, they are held regularly, and the main goal is met by the results of each such meeting - a plan is created for the next iteration. If you treat this procedure not "formally", understand its goals and objectives, know the most typical problems arising during retrospectives in advance, you can create favorable conditions for the development of a real self-organizing team .