We usually share on this blog our technical expertise around web and mobile development or architecture. Today, I would like to address another expertise, equally important: our methodology.
At Eleven Labs, our agile methodology is mainly based on the SCRUM framework. I will have the opportunity to share other blog posts to describe more precisely our methods and tools. In this article, we are going to talk about a must-have of all the agile methods, and perhaps the most widely used agile ceremony: the retrospective meeting.
We will focus on the SCRUM sprint retrospective in the context of a web development project, but most of the tools mentioned here could be used with any other agile frameworks and almost all types of projects.
At the end of the sprint, or the end of any other development cycle, the purpose of the sprint review is to analyze the product increment developed during this iteration, i.e. 'what' was built, whereas the purpose of the retrospective is to look at the processes and tools used to achieve this, i.e. 'how' it was built.
The ultimate goal is to make the team even more productive for the next cycle. In other words, the goal is to increase the velocity (number of points delivered by the team during each iteration) and the quality of the product.
In concrete terms, the discussions during this meeting should make it possible to write an improvement action plan. The team must commit to follow these actions during the next iteration. These actions can be described as technical 'stories' or 'improvements' prioritized within a dedicated improvement backlog, and each can be assigned to a particular member who then commits to carry out this task. Therefore a dedicated capacity of the team must be reserved to be able to handle these actions in parallel of other functional 'user stories'.
Each day we obviously have many opportunities to improve our tools or processes. However the team usually tends to rush because of day-to-day emergencies. It's therefore decisive to schedule regularly a dedicated time for the team to meet, step back, and find ways to improve on the long run.
This meeting usually takes place at the end of each iteration (sprint or release for example), and allows to build a strong base for the next ones.
That's why we talk about continuous improvement: at the end of each iteration, we learn from previous experiences and adapt our processes step by step.
Whether it be at the beginning of the project or years later, a team can always get better. It's best to be in a team that is able to learn and improve than being in one always stuck at the same stage.
Like every agile meeting, and in order to be more efficient, the retrospective must always be time-boxed.
To ensure this maximum duration is never exceeded, this timebox has to be clearly announced before the meeting even starts. In addition, a member of the team can be entitled with the role of 'Timekeeper'. His role would be to regularly inform the team about the time spent and still to spend. To be noted: his role is only to notify the team about the time. He should not interrupt the meeting and discussions by all means or urge everyone with this timing.
We commonly agree on the fact that this ceremony shouldn't last more than 45 minutes per week of sprint, i.e. 1 hour 30 minutes for 2 weeks iterations. It may even be possible to reduce this maximum duration to 1 hour with a more experienced team.
For larger teams, if we want to decrease this total duration along with the goal of letting everyone speak, it may be a good thing to timebox every member's speaking time, or to split the team in smaller groups. We will focus on these techniques in the next parts.
Every member of the development team (developers, testers...) along with the Product Owner (or Product Manager) participate in this retrospective. Thus, thanks to this ceremony, the team can improve its development processes, and the Product Owner can focus on improving his communication or his specifications, so that the whole organization becomes more productive in the end.
Generally, every stakeholder working on a daily basis and in touch with the development team can participate. For example, it can be interesting to make the ops team supervisor -who is delivering the team's product to production- participate if he's not a part of the development team already. It's crucial to involve him as much as possible in this continuous improvement cycle because, if the team aims to be more productive, not only it has to produce more, but also to deliver its products on the final environment.
On his side, the SCRUM Master acts as a facilitator: he makes the tools available for everyone and helps the team to self-manage and plan its improvement actions. His role is more important when the project is starting but with experience, the self-managed team will be able to lead this retrospective on its own, without him. This will allow the SCRUM Master to focus on the external disturbances instead following the team's internal improvements.
Anyway, in order for the end of retrospective planning to be viable and for the team to be able to commit on its application, it's better if the planning has been thought out without any constraint from the top management. It's for the best that no manager should participate in this meeting. In the case of the role of SCRUM Master being held by a project leader or manager, he should restrain himself only to his role of facilitator and leave the team free to choose its improvement actions.
To make this retrospective well organized and animated, many tools can be used to lead the discussion toward the set up of the improvement action plan. Here are a few of them, to be used at different steps of the retrospective meeting:
The first step is to initiate the discussion and gather everyone's opinion to get a good vision of what went well and what went less fluently during that last iteration.
Before starting to talk, it may be good to have a global vision on how every team member is feeling. To gather this data we can ask everyone to give themselves a grade from 1 to 5:
For these grades to be objective, they have to be given anonymously. The facilitator can then gather the results of the vote and communicate them to the team who could then analyze them.
The goal is of course to reach -on average- the highest possible grade, to bring the discussion the farthest as possible.
If the team is globally not confident enough to discuss any subjects, possibly tough ones, which have to be discussed anyway, the facilitator could make the team members feel more at ease by explaining again the objective of these retrospectives and continuous improvement. It's also possible to divide the team in small groups to create a better atmosphere for the discussion. Moreover, the presence of a manager may have a negative impact on the average grade of the team.
In the same way, the 5 grades of the Safety Check described above can be displayed in a funny way, using pictures, characters or smileys reflecting the level of confidence.
In the case of a serious issue, a single word can be enough to initiate the discussion. With experience, the facilitator will be able to feel this kind of situations even before starting the retrospective, and will be able to propose to the team members to write one word only on a post-it, within a limited amount of time, before any member can explain his word in front of the whole team.
The most common practice, and usually the most efficient, is to ask to everyone to summarize their ideas on post-its according to different categories:
No matter the categories, the idea is to define a short time (5 to 10 minutes) during which everyone puts their ideas on post-its. Then every member takes turn and goes to pin it on the board, in the right category, while explaining his point to the team. The last person to go, or the one who volunteers, could then gather the similar ideas to help the team achieve a global view of what has been pointed out.
For larger teams, this kind of exercise may take too much time. A solution can be to limit the number of post-its per person to make sure everyone stays concise and focused about what he has to say.
In order to revitalize team which may become used to a unique kind of retrospective, it's possible to switch from one of the techniques listed above to another, and so on and so forth.
To empower the communication and better understand the issues encountered by the other team members, here's an exercice worth practicing: the facilitator asks each member to write down his points (sorted out as explained earlier) and to hand them over to him. The facilitator can then pass them on to another team member, without revealing who wrote them. This other team member should now interpret them, and explain them to the team as if he was the author, before trying to guess who actually wrote them.
In the same perspective of walking in other team members' shoes, a variation of this exercise consists of writing two words describing one's feeling, on two separated post-its. One post-it should then be passed to the person on the left and the person on his right. The two receivers should then try to interpret the two received words.
To gather all data of an iteration, we can also ask the team to draw the sprint history, from the planning to the retrospective. This way everyone comes and adds their missing facts on the chronological line drawn on the board, explaining each fact, positive or negative.
An iteration of the SCRUM sprint kind being short, this technique doesn't always make sense, because it's not always easy to put a specific fact at its right place on the timeline. So this exercise is usually used with long timelines, for a release retrospective, or a whole project.
The previous techniques allow to have a good insight on the problems encountered by the team. Before establishing an improvement action plan, we have to find a solution for each of these points.
On the previous step, we've seen that anyone could express, in many ways, both positive and negative points in front of the rest of the team.
When it's essential to stimulate the team, the facilitator can ask anyone to dig a bit deeper into their personal analysis, by asking everyone to work on each negative point and turn it into a positive one along with an idea of improvement. This way everyone will share only positive points or improvements in front of the team.
Not only does it help boosting the teams' spirit, but this technique also allows to find more quickly the solutions which will help establish the actions plan.
This method aims to guide the team, by facing it with 4 successive questions, so it can decide on the actions to run:
This facilitation framework allows to guide the discussion, to make it very productive and to quickly get to a plan of actions for improvement.
This last technique is quite simple, and consists of asking 'Why' 5 times in a row when a problem has been identified until getting to the root of it, which tends to stay hidden. Once the root is known, we can find the appropriate solution more easily.
If you practiced well the previous techniques, you should now have a good vision of the issues your team were confronted with, and you should have identified potential solutions and improvements. Now you have to reach an agreement about a actions plan.
Keep in mind that the self-managed team should decide on its own of its actions, and then commit to run them in time. These decisions shouldn't be in any way commanded by a manager.
It's better to privilege quality of actions over quantity: it's enough to commit on two or three actions truly impactful to be realized between now and the next retrospective.
One of the first things to do before deciding about the next plan of actions is to confirm that the actions of the previous retrospective have been implemented. If that's not the case, maybe they are not current anymore or maybe the team couldn't spend enough time on these actions of improvement or maybe nobody has been in charge of the task. In either of these ways, to read again will give insights and maybe other ideas before establishing the next actions plan.
If many ideas have been mentioned, it's time to select the best ones! It's actually quite simple: ask everyone to vote for their favorite ideas. Everyone has the right to vote for a maximum of 3 ideas for example, then the 3 most popular ideas can be saved.
There is no such thing as little improvement! If you lack the ideas or if every process is already up and running, try and think about little improvements that could save you 2 seconds every day: Keyboard shortcuts, automated tasks...
For those of you who are already used to run this kind of meeting, I hope this post was able to bring you new ideas to organize your next retrospectives. It could even be interesting for you to plan retrospectives of retrospectives to make these ones always more fun and productive!
For the rest of you who didn't practice yet, I hope this article will give you a supportive insight, and motivate you to start your first continuous improvement cycle. Even though it may seem delicate to talk that freely about the issues you're facing -potentially with other team members- do not hesitate. Discuss without restraint, and you'll notice that when a meeting is well organized and based on all these tools, the outcome is always productive!
Don't hesitate to share your own retrospectives experiences by commenting below.
Sources :
Author(s)
Charles-Eric Gorron
Software Solution Architect, Team Leader & Studio Director @ Eleven Labs
You wanna know more about something in particular?
Let's plan a meeting!
Our experts answer all your questions.
Contact usDiscover other content about the same topic
The purpose of this post is to show the power of a Slack bot that can be used to ease everyday life in your company, and how to implement it using DialoFlow and Symfony
We will show you how to check the spelling in your markdown documents, changed in your pull requests, very easily using Aspell and Travis CI