Holding retrospectives is the activity each agile team conducts in order to solve its problems. What is a retrospective? This is a regular meeting where the team discusses their workflow and make changes to improve current work process.
Why do we need retrospective?
There are two main reasons. First of all, if a manager comes with the solution “not invented here” phenomenon appears. Even if team members understand it’s right decision and it should be implemented, they haven’t the sense of property related to the solution. Such decision isn’t worked out by the team, this is dictated rule and has fewer chances to be implemented.
Secondly, now development process is a very complicated thing. There is hardly a specialist that not knowing the context can describe team’s workflow to get a right solution. To clear up it something has to be attempted, experimented, what do the right things get the team. Conducting it can be clear this practice is approached or not by the team.
Nevertheless, there are such things as a good development practice and best development practice. These practices are implemented by different web development teams. For example, code review. Is it good or bad practice? It’s useful for some teams, but others implemented it without success. This is because the practice is naturally not good and not bad. It can be evaluated in the context of a specific team or a condition.
Goals and Results
The conception of Deming’s circle underlies the retrospective. PDCA (Plan-Do-Check-Act). The aim of a retrospective is to get the change plan to its end. However, it has to be understood, this is the plan of the experiments to the next period, not the final changes. We tried something and then we examined what happened. And make a decision based on the results.
Retrospective, as any team meeting, should have a goal. The aim of the retrospective is to get the practical plan of process experiment. However many teams don’t understand it. For example, the teams sometimes try to invent some global solution and face with the impossibility to make a decision. They are lost and doing nothing. If the team faces with such problem, it has to be explained that moving should be step-by-step, trying different methods and examining what to do.
The types of retrospective
In general, retrospectives can be divided into several types:
- A retrospective in the most general sense of the word;
- Quality retrospective;
- Issue retrospective;
- A retrospective on any single issue.
In general, the aim of the retrospective is the understanding what's going on, teams’ problems, what should be done. Sometimes it’s called psychological retrospective. As a rule, it begins with the question “What are issues for the team?”
Quality retrospective comes to the discussion of incidents taking place or unsolved issues. The retrospective is devoted to discussion of faults, why they appeared. Team members design graph of pitfalls and problem reasons.
There are retrospectives devoted to customer’s problem. This is the third retrospective type. The fourth type is when there is specific issue and retrospective is devoted this problem.
What’s the problem
During retrospective, process dysfunction can be detected. For example, one of the dysfunction is: the team think that there aren't problems, its workflow is well enough and there is no sense to improve it. In fact, this is not the case. But it’s hard to explain to the team.
The useful decision to change team’s position is meeting with stockholders, customers who know the team problems. Customers can be satisfied team’s workflow, but as practice shows, they always have thoughts “what team can do better”. If such customer comes to retrospective and explains his thoughts to the team, developers haven’t way out and begin to discuss the issue.
One more dysfunction is the case when speakers are only 2-3 team members and the rest is passive. Actually, they have something to say. If the team lead takes all attention, he/she begins dominant, and others just listen to him.
Why is it bad practice? If everyone is openly critical, the ability to find the best decision will arise. When we take part in group discussion, that will make us more productive. This practice helps to work out the appropriate decision.
Retrospective format: interesting practice
What is Six Thinking Hats Method
Different retrospective forms are described in Management tutorials - from simple to hard specific. So, there are a lot of sources describing Six Thinking Hats Method. And I try to explain it in a nutshell.
Six Thinking Hats is the method of thinking organizing, the main popular methods of brainstorm.
It’s not secret human thoughts are chaotic. There are emotions mixed with logic, feelings with facts. But what if on the next time, when you need to make a decision your team will try to implement all these chaotic mixes: facts, feelings, critical thinking, positive point of view, creative thinking. In the Six Thinking Hats Method context it means to try every hat: white - information, red - feelings, black - critical thinking, yellow - optimism, green - creativity. And the blue hat is devoted to discussion of the logical implementing this method. Full information you can find on WIKI.
As I’ve mentioned, the retrospective is the team meeting, where the goal is discussion the sprint and its result. Classic questions are: “What was great?”, “What are the ideas to improve the process?”, “What is planned to the next sprint?”.
And the great idea to look into the last sprint on the different point of view and don’t let to miss anything. Actually, the retrospective means to unite the team. And the Six Thinking Hats can be the effective way to do it.
For example, I tell about our practice. First of all, it was important guys didn’t loose the goal of our retrospective. So we have the retrospective plan:
- Pluses. What was good during the iteration.
- Minus. What are the problems our team faced?
- Ideas. What are ideas to improve our workflow?
- Plans. What are we planning to do?
So, the team has a general idea how the method works.
Blue Hat = management
Blue Hat is the organization of discussion process, retrospective. In the Agile context, the blue hat belongs to scrum master during all retrospective. (Especially he organize the discussion process and look after its coherence).
During this step, it’s important to tell about agenda. For example, every team member try every hat, it helps to look at the problem by means the different points of view. At the same time, the time of trying the hats should
be limited. So, the team makes the solution in time. Also, the time to resume all thoughts is needed. All received information has to be fixed and structured.
White Hat = information and facts
On this step, every team member tells facts about current sprint, for example:
- We haven’t had time to do this task,
- Release was great, customer is happy,
- … became to do front-end tasks, because guys didn’t have time.
Red Hat = emotion and feelings
In this hat team members tell about their feelings from the last sprint, show their emotions (don’t let getting personal). As facts, emotions, and feelings are very important, they can be positive and negative. And at the same time, they should be clearly formulated.
Black Hat = critical thinking
On this stage of discussion, you can take a look at fixed facts and criticize them. For example:
- If the skills of the team members were taken into account during planning, we wouldn’t lose a lot of time to…
- If the interface was worked out beforehand we would do it in time
Yellow Hat = optimism
In this hat, we choose positive facts. What was good during this sprint. For example. At the end of the sprint, the team has great results. And so on.
Green hat = creativity
Till this step, the team has fixed facts about workflow during the sprint. Team members discussed minuses and pluses. The right time to look at one more time: how to avoid these minuses in the next sprint. How to save the pluses and improve the current workflow. Here we generate and fix ideas how to support the teamwork.
Upon the results of the retrospective, the team should have the plan of improving on the next sprint. Every team has its own modernization plan based on the retrospective results.
It should be mentioned, the retrospective formats can be different. The important thing is: retrospective is the regular event, and in the result of its meeting the goal is achieved, the plan for the next iteration is created. If to understand the retrospective goals and tasks, beforehand to know about typical problems during iterations, the favorable conditions for the self - organizing team can be provided.