This is why your agile retrospectives don’t work
Every team doing scrum will (should really) be doing a retrospective each sprint. This means that the team gets together and discusses what went well, what went not so well, and what could be improved. The idea is that these regular retrospectives become an engine of “Kaizen” or Continuous Improvement for the team.
How do retrospectives work, exactly?
Retrospectives are scrum ceremonies that happen every sprint (usually on the last day, so you can talk about how that sprint went), and are facilitated by someone. That person is often the scrum master but isn’t necessarily. Some people recommend that a scrum master from another scrum facilitate the retro, so you get an outsider’s perspective.
Each person in the scrum team should attend. That’s the developers, the Scrum Master, and the product owner. Yes they are invited and should attend also, see a good article about that here).
When it starts, each person can put forward their thoughts and ideas about the sprint that has just ended. Keep in mind the focus should be on the how rather than the what. E.g. rather than “I didn’t like the look of that new menu we built, the colours look a bit stupid to me” (the what). You might instead want to say something like “I don’t understand the process for designing our UI, the visual designers don’t seem to listen to anybody’s feedback” (the how).
All kinds of feedback are welcome, positive and negative. The team’s thoughts are usually put into categories like “worked well / didn’t work well / lessons learned / I don’t understand this”, or “stop this / start doing this / more of this / less of this”. The team might then discuss or vote on the top feedback items, so the team can share knowledge, learn from mistakes and improve over time.
While this sounds great, a lot of teams find retrospectives quickly become frustrating. People come up with grievances and suggestions that get recorded and then forgotten. Sprint after sprint, the retrospectives are held but nothing is really done.
People get disillusioned. Sometimes they will bring in an agile coach or consultant, who will recommend that you change your retrospective format from this one to another one (e.g. rephrase it from “Stop Start More Less” to “Worked Well Worked Badly Lessons Learned” or “Anchors and Engines” or a hundred other variations). This will bring in a bit of fresh air, but will probably result in no major changes.
So why aren’t the retrospectives working?
People will usually try fixing agile retros by changing the inputs (inviting different people, getting a different facilitator) or changing the process (the questions or structures around the meeting). But the problem is usually with the outputs. The top items that are chosen at the retrospective could be anything: a list of grievances, questions, or general ranting and complaining. What is expected to happen with each of these? Something concrete is only going to happen after a retro if the outputs are concrete action items with assigned owners and timeframes.
For example, say someone at the retro has a complaint that “the build server is crap, it keeps falling over”. There is agreement amongst the group that this is one of the main problems the team faced this sprint. That’s fine, and the scrum master can take a note of that, but what is to be done about it? This is a legitimate issue but there is no clear action item. The facilitator needs to turn that complaint into an action item, which is usually done by “Five Whys” analysis. Example:
“The build server is crap.”
“Why is it crap?”
“It is slow and it keeps crashing.”
“Why does it slow down and keep crashing?”
“It runs out of memory.”
“Why does it run out of memory?”
“It’s just one server and there are now 20 teams using when it was only supposed to support 5”.
“Why is there just one server for so many teams?”
“I don’t know, I think someone from the platform team was supposed to set up another one but they got pulled onto other work.”
You see? Now we have a clear action item: go talk to the platform team and ask if they can prioritise setting up the new build server.
It’s not quite that simple though: the action item needs to be given an owner and a timeframe. It also needs to be tracked.
Tracking and assigning Continuous Improvement items from a retrospective
The only valuable outputs of a retrospective are Continuous Improvement Action Items. These need to be concrete tasks that someone can actually do, not “environments were bad this sprint” or “I don’t know how that API works”. They need to be assigned to a person (usually someone in the scrum) and be given a timebox (usually, the end of the next sprint).
The next important point is that they need to be tracked. The best way to do this is to put them on the team’s task board – this might be a traditional cardboard and post-it note kanban board, some kind of digital bug tracking tool, or something else. But the action items need to go on there and go into the sprint.
Do not estimate them or assign them points, they are not user stories and do not contribute to velocity or anything like that. Every team should be dedicating some time to continuous improvement. If your product owner doesn’t support them, sack them and get a new one that does, or show them this:
continuous improvement
Following up on Continuous Improvement items
You also need to follow up on these action items and see where they are going. An easy way to do this is to start each retro by looking at the action items that came out of the last retro. If they haven’t gone anywhere, you should either escalate them, give up on them, or persist with them. If you persist with them, then you shouldn’t take on any more (or many more) new action items. Continuous Improvement action items have WIP limits too!
Are you ready to move beyond retrospectives?
What a lot of people don’t tell you is that retrospectives are all fine and good, but they are not true continuous improvement. I wrote an article explaining more about this concept, if you’re interested: retrospectives are not continuous improvement.
