This is an article I wrote for LinkedIn in March 2025, published here for posterity.
Recently, I joined the sprint retrospective of a team I work with, because I was curious about their ways of working. They did the typical collaborative start-stop-continue format, which is one I quite like and often use myself. However, after arranging a bunch of post-its in neat columns, each containing a suggestion from a team member on something to start, stop or continue doing, they wanted to end the meeting.
Wait, I thought. What was the point of this exercise if there were no actions and no accountability? Sure, everyone was able to voice their opinions, which has some benefit. But to actually create tangible value, suggestions for improvements must be turned into actions and the team members must hold each other accountable for carrying them out.
It happens that teams are hesitant to create action items themselves, believing that any decision must go through management. While this may be true in some cases, like decisions that directly impact the product or business, teams should never ask for permission to improve their own ways of working. Engineering Managers and Staff Engineers should support teams self-improving and not intervene unless requested or if circumstances demand it.
The start-stop-continue format often yields items that aren’t directly actionable, or too many suggestions to practically implement in a single iteration. Voting on which to action and selecting only the top-voted ones for each iteration is a simple way to limit the amount of work, and to ensure that only suggestions on which the team broadly agrees get implemented. I like to put these actions in the team backlog, just like other tasks to be done during the iteration. This gives them visibility and allows the team to prioritize them against other commitments.
Finally, remember that putting the whole team in a meeting is expensive. Given eight members and a one-hour meeting, that’s a full workday. Some of the high performing teams I’ve been in would build, test and ship a whole feature in less time than that! While a team’s continuous work to improve itself is a force multiplier that is worth much more than the time spent, this is only true when improvements are continuously suggested, actioned on, and evaluated.