The way to a team’s perfection is an everlasting journey. It starts when the team is set up and ends when it is dissolved. How long it takes depends on the purpose for which the team has been created. For some teams it might be 3 months and for some a year or longer.
A self-organized team, when brought to life, defines a number of rules and principles which are used in day-to-day work. The aim of those rules is to provide high quality software in the shortest possible time. It might happen that some of the rules are enforced by the organization for which the team is working. No matter what the origin of the rules is, after some time some of them tend to be outdated. However, more often the team realize that some of the rules are missing. This comes with no surprise that at the beginning of the project it is hard to predict what will be needed after some time. It is hard to predict the changes which will occur in a product, in a team and in a technology.
Retrospective is a stop on a team’s way to perfection which becomes an opportunity for self-improvement (e.g. communication, performance, quality, etc.).
In Scrum, a Sprint Retrospective is an event which is held at the end of each Sprint. Scrum Guide defines Sprint Retrospective in the following way:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The goal for the Scrum Team is to increase the product value with each Sprint (iteration) and to improve itself such that a better increment can be provided. From my experience a better team equals a better product.
The Sprint Retrospective is designed for a whole Scrum Team and includes: Development Team, Scrum Master (who is responsible for making sure this event take place) and Product Owner. It is not intended for management or stakeholders. However, the Scrum Team can invite whoever may bring value to the meeting. There are some situations in which the Product Owner might be excluded from this meeting but this is a separate subject and I will try to write about it later.
The Scrum Guide defines a time-box for a Retrospective meeting. For a 1 month long Sprint it should not take more than 3 hours. For the most popular configuration, 2 weeks long Sprint it should not be more then 1,5 hours.
The basic recipe for the Sprint Retrospective is:
- Based on the Sprint which is about to end a team should gather information (inspect) on what went well and what can be improved. Do not focus only on the technical part of the project like development stack, tools, etc. but also include aspects like relations between people, communication and processes.
- Prioritizes what is the most important for the Scrum Team. Consider what has the biggest impact on the team and the product.
- Create a plan how to preserve what is good and what can be improved and do it.
My way for the Sprint Retrospective starts long before the first meeting. To allow the Scum Team to provide relevant and valid information, the team need to be aware – i.e. things which make theirs work easier and things which make it harder. The team needs to be aware that at the end of each Sprint, starting from the first one (there is no Sprint 0, but I try to write about it some other time), there will be a Sprint Retrospective meeting. To ensure awareness, I am sending an invitation (reoccurring invitation) to each team members with a description of this meeting (what is for) at the beginning of the project.
The meeting is proceeding in the following way:
- Let’s become / Icebreaker and agenda
This is the part in which a joke can be told or just a 5 minutes pep talk to make the atmosphere a bit more relaxed. There are a lot of opening exercises for the team which might be applied. Before the inspection starts it is important to present (or remind) the agenda of the meeting and agree for the rules which the team should follow during this meeting (time-box 10min). I would like to emphasize one rule which is for me the most important: No one should be blamed by anyone! - Let’s check how we are doing / Monitor the progress
This part does not take place during the first Sprint Retrospective as it is designed to monitor the Action Points from previous one. Before the team starts to work on new problems/challenges, the team needs to verify if the plan established in previous meetings has been fulfilled. It might happen that some of the actions planned by the team become obsolete, impossible or too expensive (in terms of effort or money) to implement (time-box 10min). - Let’s gather some input / Time to inspect
It might happen that each team member will have already prepared a list of things that he/she liked and list of things he/she disliked in ongoing Sprint. If not, you should give them some time to make such a list (time-box 5min). Once this is done everyone should present it. It is very likely that more than one person has thought about the same thing or very similar one. That’s why it is very useful to group them (time-box 10min). - Let’s talk
Once all issues have been presented, the team should talk about each problem to better understand what impact it has on the team and/or the product. It is also a good idea to talk about positive things and how to preserve them (time-box 15min, it can be prolonged if there are a lot of issues). - Lest make a vote
Since the team is not building the whole product in one Sprint, it won’t be possible to resolve all problems in one Sprint either. The team should decide which problems/challenges they will address first. It might be one or more things (I would choose 3). It is important the team will select them jointly – in a democratic fashion. The most common way (and the easiest one) is a voting. Each team member has 3 votes which can be freely distributed: 1 vote for 3 items or 3 votes for the one it is the most important for him/her. We sum the votes and the 3 which got the highest number should be resolved by the team first (time-box 5min). - Let’s make it happen, but how?
Once problems/challenges are selected, the team should discuss them again and plan how to mitigate/resolve them. It is a good practice to create action points as it is easy to monitor them (time-box 10min each).
Bear in mind that some subjects need more time to be properly address. In such cases a separate meeting should be held.
There are several techniques to make each part of the presented Retrospective more attractive. Google has them all but I will try to present some of them in more details in some future posts anyway.