How we screwed up and fixed the retrospective process in agile teams
Once the start-up era started we helped with building MVPs to a number of successful start-ups. These projects often had two things in common — a team of less than 3–4 people, and a duration of 2-3 months. Working in a company with many small projects, it is hard to keep the same team makeup for a long time as people move between teams and projects often. Constant change affects the retrospective learning process so badly that the process stops entirely. And it did stall for months before we understood what was wrong.
We at Mobi Lab found a way to keep the process going and relevant even in this kind of situation.
The loop of learning
Regardless of how your teams work, be it Scrum, Kanban or some other method, you want to have a learning loop in the process. You regularly gather your team, look back and discuss how things went, what was good, what could have been done better and how to improve. Doing so allows to notice and address problems and to take explicit actions to fix them. This kind of process is often called the retrospective meeting and the actions themselves are called Action Points.
By the book, the retrospective meeting happens when certain milestones in a project have been reached — a sprint has completed, MVP delivered, the result of a week of work released, etc. But if you have a lot of small projects with 1–3 person teams then it is hard to keep this process going. For example, the team could be just one Android developer, a designer, and a Product Manager.
The fewer team members you have the more they feel like they are already discussing everything anyway and they do not need the extra meeting and the explicit process. This feeling is deceptive and only works as a way to stop the learning process completely. Don’t fall into that trap as we did initially.
Keeping the loop of learning alive
We found that regardless of your team size and set up there is a way to keep the retrospective process going. You just need to create separate teams for the process itself.
At first, this can seem counter-intuitive — isn’t the process a way to improve team’s work by applying learning? Between a team of people who actually work on the same things? If there is no team then why create one only for the sake of the retrospective?
The answer is actually very simple. If you do not have consistent teams then people still work together a lot — just in different teams. Their problems are still the same. The learnings are still needed. So you can just take people randomly and make retrospective teams out of them. Keep the teams small, but not too small — after some testing, we found that 5 to 8 people works well. If you have too few team members, then it is hard to get the discussion going, if you have too many, then it is hard to keep the discussion on the topic.
Making these teams and setting up meetup times in regular intervals helps us to keep the learning going.
Keep the loop of learning interesting
Another problem we regularly struggle with is keeping the meeting interesting. It is easy to say that “do a regular meeting and learn”, but in reality, too much repetition gets boring very fast. And when it gets boring then the leaning part will not work. We found two things that helped us in this regard:
Firstly, we divided our weekly retrospective meetings into two: regular retrospective meetings and topic discussions. And started doing them biweekly — one week is the retrospective meeting, the other is the topic discussion.
On the retrospective meeting, we mostly follow the tried and true strategy — we play a retrospective game and through that analyze how are doing, find out what helps us and what slows us down, and set our Action Points to fix the latter. Next time we review the Action Points and repeat with a new and different game.
On the topic meetings, we discuss questions and problems we have picked beforehand. We have a topic box that both team members and other stakeholders can use. At each meeting, we discuss one of the topics from the box, and at the end pick a subject for the next time. We found that it is very important to let the people know the topic beforehand and also to set specific goals to the meeting. This way people have the best chance to prepare and we can keep the discussion topical and concise.
It also turned out that a good source of those topics is the retrospective meeting itself. There is a certain set of problems that come out that have no easy fix to write into an Action Point. For these cases, we write it out as a topic with elaborating questions attached and put it into the topic box. Perfect source material for another topic meeting.
Secondly — all work and no play makes Jack a dull boy. That is why we, from time to time, skip the retrospective game and do something different. We visit art galleries, museums, offices of other companies, etc. This keeps the meetings interesting, allows the team members to interact outside of offices and gives people a chance experience fun things together. We also try to keep the events short so people who can come to the regular meetings can also just as easily attend these outings.
Conclusion
Our system of retrospective teams and variation between two styles of meetings allows us to tackle both personal and team learnings and to always find time to discuss and decide on issues that affect us as a team and as a company. Try it out in your team:
- Form joint retro teams outside of projects space
- Schedule bi-weekly retrospective and topic meetings
- Make it fun and interesting
- Let me know how it went in comments below
Mobi Lab is a product design and development company. We run our product development in-house but also work in joint teams with clients in Europe and US. Mobi Lab is one of the fifty Google Certified Agencies for Android technology.
