Agile Retrospective for team improvement
12 Apr 2020Agile has been followed in some form or the other all the software development teams that I have worked for. Most teams used sprints and daily scrum meeting only. Some teams used sprint planning meetings where you decided the ticket that you would work on during the sprint.
I have often seen that the Product Owners or Team Leads bring in work as they see fit into sprints without any formal sprint planning meeting. Usually there is some informal followup where people discuss if the work is being done and whether enough work in brought into the sprints.
In my current organization, we do a lot of meetings related to agile methodology like sprint planning, grooming and retrospective. I was not initially on-board with the idea of conducting so many meetings as I thought that a lot of collective hours are being spent on meeting instead of actual work. But of late, I have noticed significant improvement in team morale, ownership and communication. So I decided to write about retrospective which I found was extremly helpful in identifying problems within the team.
Retrospective meeting is conducted at the end of a sprint (before sprint planning) where the team reflects on how well they did in the sprint. The meeting is used by the team to raise issues that they are facing and how they can fix them.
The meeting can be divided in three phases - idea generation, discussion and solution. Each phase is time boxed so that we do not run out of time. 15 minutes each would be a good start.
Idea generation
Team members use sticky notes to come up with ideas or notes around these three themes:
- What went well? This is for the team to feel good about their work and learn their strong points eg, there was a complicated migration that the team managed to push out.
- What caused confusion? Sometimes due to unclear tickets, processes or inadequate training some team members can feel confused or lost. This is where you can identify those problems.
- What went wrong? Things can go wrong for a lot of reasons like miscommunication, poor planning or external dependencies. These issues need to be identified and discussed.
Discussion
Once you are done with idea generation phase, you need to arrange your tickets in three columns - one for search theme. It should look something like this.
Image courtesy: https://waynedgrant.wordpress.com/2012/04/01/sprint-retrospective-techniques/
Now the team should discuss these ideas and get clarification if they couldn’t understand something. At the end of the discussion, you can discard the “what went well” ideas since your team is already good at it.
The ideas under “what went wrong” and “what caused confusion” should be merged. Similar ideas should be grouped to create a common theme. At the end of this phase, you should have identified some common problems in the team which needs improvement.
Solution
In this phase the team should vote on top 2-3 problems which they would like to address immediately in the next sprint. The team can either collectively come up with ideas or use sticky notes to individually come up with ideas for every problem and vote on it.
At the end of retrospective meeting, they should create tickets for team improvement and add it to the next sprint. These tickets should be reviewed in their next retrospective to see how well they did on addressing these problems.
It takes some time to get used to retrospective, but over time I have found that it solved lot of friction within the team and helped us collectively figure to out solutions to the problems.