Flexible methodologies. Retrospective
Retrospective (from the Latin. Retrospectare, "look back") - a look into the past, a review of what was in the past.
In flexible methodologies, there is such a thing as a “retrospective”. At first glance it may seem that this is an absolutely unnecessary element. But I know for sure that using retrospectives has improved the development process in my team.
So, several definitions:
A retrospective is a meeting that the project team holds at the end of each iteration to discuss what we have learned as a team and make plans for the next iterations based on the lessons learned.
A retrospective is a team activity revising the closest period of team work time in order to improve the work process of the same team in the same project.
')
Everything sounds quite simple and logical, but our team managed to make the retrospectives useful and effective not immediately.
What is needed for a retrospective?
1. The team (Agile advises to collect everyone, including customers, but we are going to only developers)
2. The room for holding - it is desirable that this would be a separate room, for example, a negotiation (that would not interfere with anyone, and that no one would interfere with us)
3. Board for drawing or fixed for drawing sheets
4. Markers (preferably several colors)
5. Time from half an hour to two (the duration depends on the frequency of the retrospectives, the number of people in a team, the formation of the team itself)
How is the retrospective?
There are several stages:
1. A survey of opinions (what was good and what was bad in the last iteration?) And fixing them on the board
2. Voting
3. Isolation and discussion of the main problems of the day (those who gained the most votes)
4. Identification of solutions to selected problems responsible for them.
5. Recording of the achieved results (Discussion of tasks that were solved according to the results of past retrospectives)
Each retrospective must have a presenter: “a person with a marker”. In the description of the methodology it is not recommended that the leader be such a leader. Our team came to the method: "baton": presenters change from retrospective to retrospective. The most important thing that should be done, or rather, NOT the leader, is not to alter the words and statements in their own way, because this can distort the meaning of the statement.
A survey of opinions can be conducted in the open, and you can anonymously (then the leader collects the leaves, with points written on them). The most important thing in the process of opinion polling is not to slip into a discussion of this problem, but only to fix it.
And never forget about the points "good", they should be asked first.
“What did you like in the last iteration?”, “What positive moments could you point out?”, “What would you like to write in the“ good ”section?” Are approximate questions asked by the team leader. Similarly, under the "bad."
By the way, the number of points, their "seriousness" and the prevalence of any section, quite clearly shows the "formation" of the team, the "set" of processes, etc.
Voting can take place in different ways. You can identify the "prioritization" of the task for a person (raising 5, 4, 3 fingers, etc.). Our team has chosen the path of limiting the number of votes. Everyone can vote only for a third of the points. (If the “good” section has 12 points, then a person has 4 votes and that means raising a hand and he can vote for any 4 points out of 12).
The presenter counts votes and writes a number in front of each item. There are the most "popular" topics in each of the sections. Usually there are 3-4 of them, these are the most exciting problems for the team and the “pleasures” noted by all.
(This is where the colored markers will be needed - to separate the numbers of votes from the item numbers and for the stroke).
Items from the “good” section are simply recorded in the retrospectives report. (The team must remember its achievements!)
But with the items from the "bad" section, you still need to work. It is very good, if the team having discussed it, comes up with a solution to these problems, or at least the initial path that needs to be taken to solve it. Here, the person responsible for the task is selected, who must do everything possible to solve it.
We, for the convenience of tracking tasks on retrospectives, get them into Jira and proceed as with normal tasks for projects.
At the very end of the retrospective, the results of past retrospectives are briefly discussed, the responsible ones talk about what has been done. ("And now we have it! And now we do this and that. We did it up last time.") Sometimes there is an adjustment of past tasks and a reassignment of responsible ones.
Starting to write an article, I realized that the topic is quite extensive. If the community is interested in learning more, I will write a sequel, where I will talk about the problems that arise and the ways we have fought with them.
In flexible methodologies, there is such a thing as a “retrospective”. At first glance it may seem that this is an absolutely unnecessary element. But I know for sure that using retrospectives has improved the development process in my team.
So, several definitions:
A retrospective is a meeting that the project team holds at the end of each iteration to discuss what we have learned as a team and make plans for the next iterations based on the lessons learned.
A retrospective is a team activity revising the closest period of team work time in order to improve the work process of the same team in the same project.
')
Everything sounds quite simple and logical, but our team managed to make the retrospectives useful and effective not immediately.
What is needed for a retrospective?
1. The team (Agile advises to collect everyone, including customers, but we are going to only developers)
2. The room for holding - it is desirable that this would be a separate room, for example, a negotiation (that would not interfere with anyone, and that no one would interfere with us)
3. Board for drawing or fixed for drawing sheets
4. Markers (preferably several colors)
5. Time from half an hour to two (the duration depends on the frequency of the retrospectives, the number of people in a team, the formation of the team itself)
How is the retrospective?
There are several stages:
1. A survey of opinions (what was good and what was bad in the last iteration?) And fixing them on the board
2. Voting
3. Isolation and discussion of the main problems of the day (those who gained the most votes)
4. Identification of solutions to selected problems responsible for them.
5. Recording of the achieved results (Discussion of tasks that were solved according to the results of past retrospectives)
Each retrospective must have a presenter: “a person with a marker”. In the description of the methodology it is not recommended that the leader be such a leader. Our team came to the method: "baton": presenters change from retrospective to retrospective. The most important thing that should be done, or rather, NOT the leader, is not to alter the words and statements in their own way, because this can distort the meaning of the statement.
A survey of opinions can be conducted in the open, and you can anonymously (then the leader collects the leaves, with points written on them). The most important thing in the process of opinion polling is not to slip into a discussion of this problem, but only to fix it.
And never forget about the points "good", they should be asked first.
“What did you like in the last iteration?”, “What positive moments could you point out?”, “What would you like to write in the“ good ”section?” Are approximate questions asked by the team leader. Similarly, under the "bad."
By the way, the number of points, their "seriousness" and the prevalence of any section, quite clearly shows the "formation" of the team, the "set" of processes, etc.
Voting can take place in different ways. You can identify the "prioritization" of the task for a person (raising 5, 4, 3 fingers, etc.). Our team has chosen the path of limiting the number of votes. Everyone can vote only for a third of the points. (If the “good” section has 12 points, then a person has 4 votes and that means raising a hand and he can vote for any 4 points out of 12).
The presenter counts votes and writes a number in front of each item. There are the most "popular" topics in each of the sections. Usually there are 3-4 of them, these are the most exciting problems for the team and the “pleasures” noted by all.
(This is where the colored markers will be needed - to separate the numbers of votes from the item numbers and for the stroke).
Items from the “good” section are simply recorded in the retrospectives report. (The team must remember its achievements!)
But with the items from the "bad" section, you still need to work. It is very good, if the team having discussed it, comes up with a solution to these problems, or at least the initial path that needs to be taken to solve it. Here, the person responsible for the task is selected, who must do everything possible to solve it.
We, for the convenience of tracking tasks on retrospectives, get them into Jira and proceed as with normal tasks for projects.
At the very end of the retrospective, the results of past retrospectives are briefly discussed, the responsible ones talk about what has been done. ("And now we have it! And now we do this and that. We did it up last time.") Sometimes there is an adjustment of past tasks and a reassignment of responsible ones.
Starting to write an article, I realized that the topic is quite extensive. If the community is interested in learning more, I will write a sequel, where I will talk about the problems that arise and the ways we have fought with them.
Source: https://habr.com/ru/post/49911/
All Articles