A project retrospective that the team will want to attend

How often did you get bored in a project retrospective? How often have you been angry that you were wasting an hour of your time on this meeting while the next task burns down sadly nearby? Did they listen to you on retro, or was everyone waiting in line to say a couple of formalities and get back to work? I was terribly tired of it once. In this article I will talk about how, using simple rules, I managed to make retro the warmest meeting of the team, not counting the corporate party.







A project retrospective is a team discussion of the problems encountered on the project and how to solve them. In addition, a properly conducted retro also brings psychological relaxation for the team. 





First, let's decide when it is possible and necessary to conduct a retrospective .



For a useful retro, you should have:






  • A completed project or a large number of project sprints in a fairly long-term period. For example, in a couple of months. If the project is large, there is a dedicated team for the project and the work on the project is being actively carried out, you can carry out retro once a month. More often not worth it.
  • Command. Preferably well-established and internal. It is pointless and merciless to conduct a retrospective with outsourcing or in a situation where your resources are flowing more than water from a tap.
  • . , . , .




Of course, if you simply ask for feedback from the team, you risk becoming the owner of voluminous, emotional and unstructured information that is impossible to work with. 


It is best if the team has a common table.



Frankly, the feedback table is perhaps one of the most important components of a well-executed retro. The table I am using consists of two sections that are filled in by the command in sequence. 





The first part is a description of the problems and a column for the solution adopted at the meeting.

It's great if problems are written impersonally, and are discussed directly at the meeting, where the employee can remain anonymous if he does not want to.



It is also good if the table has two columns to describe the problem: a column for a technical / organizational problem, etc., and a space for an orah. In this way, we subtly help a colleague to distinguish between their feelings and specific problems.





My spreadsheet usually has two columns for the team to share their emotions. In the first, I give people the opportunity to throw out their negativity, answering the question: "What was wrong?" After the righteous anger has been released and has burned the hearts of sympathizers with a verb, I ask a neutralizing question: "What was good?" It is extremely important to discuss with colleagues not only negative aspects of even the most difficult, jerking, sprints. Even if the sprint is not successful, and you have loud letters from a client in your inbox, the team must find positive aspects of this experience. Your team needs to learn to find positive moments themselves, even in the most trashy situations. 





The second part is voting. Of course, each employee's own pain and opinion is a priority. But it's worth remembering that we work as a team. After all the problems have been discussed, the whole op has been heard and positive points have been found, it is worth highlighting the three main problems (and their solutions) that you and your team will implement over the next month.





Do not try to solve all the problems with a retro look, it is impossible. Try to follow the rule at each retro: 





Three problems - three solutions



You will spend another month implementing these solutions, getting the team used to the changes and identifying pitfalls. It's great when the team prioritizes these issues. For this, we have a part with voting in the table.



Voting is extremely simple: each team member has three votes, which he is free to dispose of as he pleases. He can put all three votes on the priority of the only problem important to him, or give one vote for each of his pains. Give the team time to think, don't rush them. Based on the results of the vote, highlight the three problems with color and do not forget to return to them in the next retro to consolidate the result and analyze the pitfalls. 




Now I want to make your life a little easier. For those who have never done retro, below there is a step-by-step instruction on how to start such a good deed>





Step 1

Determine if we need retro. We allocate two hours of time for retro. It is advisable to conduct a retro one a day after the release, when the hotfixes are already pumped up, the team has been released and has not yet been covered with new tasks. 





Step 2

Create a table.



Step 3

Putting the team together for a five-minute stand-up. We tell you in a nutshell what kind of beast this "this is your retro" is, show the table. 





Step 4, which is important not to ignore.

Allocate each team member 30-40 minutes from the schedule to fill out the table. Let them know that they have time for this. Let them be able to fill it out calmly. 





Step 5

Get ready for the first retro to be disgusting. Expect your table to have either mate or blank lines. Until your team understands why you are doing this, and for them it is a waste of their precious time in which you can do something useful. Be patient and loyal. Prepare the positive nuances of the past sprint, enter them yourself in the table. Oh yes. Stock up on a sedative.



Step 6

Invite your colleagues to come to retro with coffee / tea, set the tradition of "retro sweets for tea" yourself. Start by vocalizing negative and positive emotions. Remove the negativity from the team, laugh and fight all together. This part is often overlooked as it is unproductive in terms of production. But it matters to you and your team. If the team wrote only negative, suggest your advantages, listen to the feedback.



An important retro rule:



The team is not listening to you. You are listening to the command.



Step 7

Then proceed to voice the problems. Make sure that at this stage the team is already back in working order and ready to deal with the difficulties. When you have discussed all the difficulties, there are sketches of solutions or an already established plan of solutions, record them in the table. 





Step 8

Vote. Explain that each team member has three votes. They can distribute them of their own free will, depending on which problem "hurts" the most, and its solution for a given team member is critical. Give your colleagues time to vote. 





Step 9

Highlight three problems that you will solve in the chosen way. Thank your colleagues for the meeting.





Step 10

Create tasks for solving the problems you have highlighted and assign responsible persons. Make sure those in charge have time for this.



Step 11

Be consistent and rhythmic. Once a month (or with another frequency) you have a retro. All decisions that are highlighted for retro a priori or are introduced, or are brought up for the next discussion, as a failed decision, in order to find a new one.



If you have the opportunity to do retro from time to time, with a fluid team and in 20 minutes, it is better not to have a meeting at all. Save your colleagues' nerves.



Make retro a good tradition. It will pay off to you.



All Articles