Retrospective: how and why to carry it out?
Conducting retrospectives is the activity that every agile team conducts in order to solve their problems. What is a retrospective? This is a regular meeting where the team discusses their workflow and changes something in it.
Why do we need a retrospective?
This is not an idle question, it is often asked by bosses when they are asked to conduct a retrospective. They ask: “Why? We can decide 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 workflow?
There are two main reasons. Firstly, if we come to a team with ready-made solutions, a phenomenon arises called “ not invented here ”. Even if the team members understand that this is the right decision and must be implemented, they do not have a sense of ownership towards it. Such decisions, not “suffered” by the team itself, but “imposed” or proposed from above, are less likely to be implemented.
Secondly, now software development is such a complicated and confusing thing that there is hardly a specialist who can, without knowing the context, describe how the processes in a particular team should actually work in solving a particular problem. To find out, you need to try something, conduct experiments, look at what these or those solutions lead to. Just by trying it, you can understand whether this or that practice is good or not very good in the context of this team.
However, there are things like good practice or best practice. These are practices that many use and that help many. Take code review, for example: is it good practice or bad? It helps one team. 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 only be assessed in the context of a specific team and situation.
At least therefore it is impossible to say in advance whether it will give any 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 retrospective is based on the concept of the Deming cycle , PDCA (Plan-Do-Check-Act). The purpose of the retrospective is to get a change plan by the end of it. But it is important to understand that this is not a plan of final changes in the process - it is a plan of an experiment for the near future. We try something, and then look at what came of it, and based on this we make a decision.
Deming's cycle: Plan - plan, Do - execute, Check - see what happened, Act - make some further decisions, decide what to do next. A retrospective should go exactly on this cycle. Actually, the retrospective itself is the Plan stage.
Retrospective, like any team meeting, should have some purpose. 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 kind of global solution to their problem, and rest on the fact that they cannot do it. They get stuck and do nothing at all. If a team is faced with such a problem, then it must be explained 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 to discuss their workflow and somehow improve it, then, as a rule, it all comes down to people coming in, talking about something, pouring out their pain, making 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 leader’s task is to bring the team in the process of retrospective to a specific plan. A plan is one of two things: either action or a new arrangement. All that retrospective boils down to is a list of actions that must be completed and agreements that must now be adhered to.
What are actions? These are specific tasks with famous performers. And if the action is performed by someone who is not in the room now, a person is selected from among those present who takes the responsibility to explain to the absent what and how to do, and also to control the result. As a result, one of those present in retrospect is responsible for each action.
What are the retrospectives?
In general, it is reasonable to subdivide retrospectives into several types:
- retrospective in the most general sense of the word;
- retrospective on quality;
- retrospective on issues;
- retrospective on a single issue.
Retrospective is generally aimed in the broadest sense on understanding what is happening in a 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?”
A quality retrospective usually comes down to discussing either recent incidents or defects. A retrospective is dedicated to discussing these defects and analyzing why they occurred, that is, they build a diagram of the root causes of defects. One way or another, in this case, work is carried out with specific quality problems.
There are retrospectives in 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 a retrospective is devoted to its solution.
What is the problem?
What dysfunctions can arise in the retrospective process, 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. This is usually not the case. But the team just can not explain it.
In order to move the team from this position, it is useful to invite one of the stakeholders - the customer or users who know that the team is not all right (customers are very rarely completely satisfied with the work of the team) for retrospective. 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 do better”. If such a customer comes in retrospect and tells the team this, she has nowhere to retreat, she begins to discuss directions for further growth.
Another dysfunction is when in retrospect basically one or two or three people speak, and everyone else is sitting and silent.In fact, these people have something to say. Simply, if all the attention is taken away, for example, by the leader of the team, he begins to dominate, and the rest just listen.
Why is that bad? If everyone openly expresses their 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, a facilitator of a retrospective helps to cope with this problem, who will ensure that everyone present expresses their point of view. Sometimes, in order for retrospective participants to express their opinions more freely, it is useful to give them the opportunity not to express their thoughts out loud, but to write them on sticky notes (they are usually attached to a wall or a special board, and this can be done by both the participants themselves and - for greater “anonymity” - a facilitator).
Retrospective format: our proposals
The literature describes various formats for conducting retrospectives, from simple to very specific. In one of the materials in our blog, we proposed our own version: its distinguishing features are simplicity and efficiency. Basically, this is exactly what is required from such events.
Instead of setting hard timing and sequence of actions, we suggest just drawing a board into 4 main areas and filling it in the course of discussion:
- Pros. What went well in the last iteration?
- Minuses. What problems were in the last iteration?
- Ideas. What ideas came up in retrospect?
- Plan. What improvements are we planning for the next iteration?
Since the main objective of the retrospective is to create a plan, all actions and intermediate steps 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 iteration. Cons and pros do not arise on their own - the basis for them is the plan drawn up in the previous retrospective, while the team itself decides where to relate one or another 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 previous iteration, however, they are not limited to: such a retrospective format does not impede free discussion. At the same time, the facilitator or the scrum master should ensure that discussions do not turn into a search for the guilty: to achieve the goal, it is important not so much “who is to blame” as “what to do next”. Disputes over this or that idea at this stage are also useless: all the same, only those ideas that all participants in the retrospective agree with will get into the plan.
After discussing the pros, cons and ideas, the team proceeds to draw up a plan, which includes not just the results of the discussion, but (as already noted) specific actions (“Perform ...”, “Discuss ...”, “Form ...”) or rules (“Task X to perform using approach Y "). At the same time, you should not try to work out ways to solve all possible problems of the team - for effective work at the next iteration, a plan of 3-6 points is enough. An oversized plan may ultimately prove impossible and only demotivates the team.
It is worth noting once again that the formats for conducting a retrospective may be different. One thing is important: retrospectives are not an isolated event, they are held regularly, and according to the results of each such meeting, the main goal is fulfilled - a plan for the next iteration is created. If you do not take this procedure “formally”, understand its goals and objectives, know in advance the most typical problems that arise during the retrospective, you can create favorable conditions for the development of a real self-organizing team .