I believe in the process of Continuous Improvement. It means that any development related process can be improved at any point of time, and theory of constraints agrees with it. Part of the process of this improvement is looking at what was done during some period of time and analyzing what went well, and what can be improved.
This is all what retro meeting is about. Some of my peers argue that you don't need to dedicate a whole meeting for that, meaning that if issue arrises, it should be tackled immediately, otherwise it it unimportant. In my opinion, there are still non-urgent issues which are worth noting, analyzing and fixing to improve the overall process. Also, retro meetings provide a point when the whole team can take a break from production activity, take a deep breath and calmly rethink what happened lately.
Prerequisites
Right people
As retro is an improvement opportunity for a team, everybody from that team should participate including product owners, designers, developers, qa engineers etc. If there is anybody who is working with the team regularly, include them as well.
Also, there should be a facilitator on the meeting - somebody who helps the team to achieve the retro result. This person should know the procedure and know the tools.
Proper execution
There are typically 4 parts of the meetings:
- brainstorming what went well
- brainstorming what can be improved
- voting for the points of improvements of the top priority
- brainstorming action items
Each part requires at least 15 minutes but may require more.
Tools
You can use trello for the retro or pick miro or use something like easyretro. Those tools will allow you to create cards, vote for them and deduplicate items in some way.
How to conduct
Schedule a meeting for the whole team for an hour, hour and a half or two. Do it in advance. If you're doing iterations, make it the on the first day or the last day of one. Prepare the board on the tool of your choice. Include the link to the board in the meeting.
Gather on the meeting, turn on the cameras, so you see each other faces. Reiterate the agenda of the meeting: what you're going to do, what is the goal of the meeting etc, what are expected timings. Ensure everybody understands the format.
When you're all set, kick off the first part!
What went well
First of all the team should recognize what they achieved and what went really well. It keeps the team morale high and allows to understand what practices should be kept in place. Allocate the time for the team to create cards with those good things. Once the timer is out, read them loud and appraise the team work.
Example:
Finished setting up the end to end tests on the CI. Now we know really fast if there is a problem in the build and we are able to fix it ASAP.
What can be improved
Mind the wording: not we did badly, but what can we improve. The former makes the people feel blame, and it is not constructive. The latter focuses on future improvements and sets the proper tone.
Again: set up the timer and make the people brainstorm the cards with improvement points. Do not suggest the solutions right away: only highlight the painpoints. Example:
Bad card:
Write more unit tests
Good card:
We make a high amount of bugs which are preventable on the development stage
The good card highlights the problem itself, which allows for brainstorming the true reason and creating a relevant solution.
Some tools like easy retro allow you even to shadow the card content so that the team members can not see what their peers write until the board admin opens the cards up for everyone.
Once the cards are in place it's time to deduplicate them. Chances are your team members will highlight the same issues with different wording, and it's better to have all the descriptions of the same problem in one card.
After deduplication you can vote for the cards which are the most painful. You do it because you want to prioritize the things that hurts the most, and fix the mere inconveniences later.
Action points
Ok, great! At this point you have a prioritized list of the issues of your current process. Now the team should discuss the ideas how to fix each of the points. Remember, that each card in this column should be actually actionable. It means having a firm, clear description of the action, responsible person and a deadline. Ideally would be creating a ticket in the bug tracking.
Remember to go through the list of action points in the next retro meeting. Make sure those items are also worked on.
Summary
In order to have a good retro meeting, grab a proper tool, figure out what went well and what to improve, then create a list of task to work on. Check on the progress of those tasks in the beginning of the next retro.
If you liked the article, make sure to Subscribe. If you need some consultations on solution architecture or software development processes, this is possible as well.