SoundCloud started its agile journey with Scrum and eventually moved to an approach based on Kanban (more on that in one of the next blog posts). Regardless of the methodology we follow, though, we strongly believe that the most important tools an agile team can use to practice continuous improvement are retrospectives. You might ask why we consider the retrospective to be the most important one? We think it is key to constantly learn and to improve based on our experiences. The best way to achieve this is to look back at our work in regular intervals and to give every team member the opportunity to give input on the past work – and to make sure we have actually improved something. This is done by reviewing action items from the last retrospective as the first step.
The most frequent retrospective meeting is done after each iteration – in our context this means every two weeks. Every three months we do a big retrospective meeting with all of the engineers in one room to find common patterns in our development department. One major result of these big retrospectives is our “hacker time” project – see here for more details. The length of the retrospective depends on the size of the team and the time between retrospectives. We usually schedule 30 minutes for the short one after each iteration and 90 minutes for big ones.
You need only a few things to do a good retrospective – you can even do one only with Google Docs – but it works best with the following things:
So, all items put under “less” are things which either should be done less or should be stopped completely. “Same” is obvious, and “more” are items which should be done more or should be started.
Why? This scheme avoids the bad/good categories often used and allows an open communication where putting a sticker somewhere does not mean something is “bad” – it allows a more nuanced conversation.
Why? Everybody can give their input, often some people tend to dominate a discussion and the other people are not heard as much. This approach enables everybody to give their input.
People are free to put post-it’s on the wall (on the three columns) anytime. Latest after 10 minutes or when nobody is writing anymore the next phase starts.
The facilitator starts grouping items into clusters to find common themes. Usually there always are topics which a lot of people mention. Every item is read out to the group and if everybody agrees put to a cluster.
This is the final test if the grouping made sense – if you cannot agree on a name the cluster has too many different items and has to be split.
To identify the most pressing issues (number of post-its in a cluster is also a pretty meaningful indicator) everybody gets three votes and can give one vote to three different clusters. The top three items should be addressed during the next iteration.
If there is time left start discussing the clusters starting with the one which got the most votes. Try to get action items out of it.
A retrospective tends to be useless if it is “just talk” and no actions follow. So the key ending of a retrospective is to to collect action-items to work on at least the top voted clusters. The next retrospective starts then with a review of the action-items from the last retrospective.
We have been doing it that way for the last 8 months with pretty good results. There are around 8 engineering teams at SoundCloud and 45 engineers overall. The key challenge is here to continue doing retrospectives and to follow up on the action items.