At Lean, we use sprint retrospective as a tool for process improvement and as a call out for errors made in the previous sprint. If you haven’t heard of a sprint retrospective before, it is a meeting held with all scrum team members to discuss the previous sprint. These meetings are usually held at the end of the sprint. We hold our retrospectives directly after our sprint review which allows the team to reflect on the work done as they just finished demoing it to stakeholders.
When the team comes together to perform a retrospective, we follow the Start-Stop-Continue model. What this means is we first start by simply going around the room and asking each team member (developers, QA, Product Owner, and Scrum Master) for one thing they would like to start, stop, and continue doing. These items could be something that would change the process in which we currently work, or something as simple as “stop pushing code that breaks the build”.
After each member of the team has given their starts, stops, and continues, we open the floor for discussion. Everyone at this point can bring up any of the points they or another member of the team have brought up. Once everyone feels that all the important items have been discussed, the team selects three things that they would like to make the focus of the next sprint.
So what’s the benefit?
The start-stop-continue model has the benefit of allowing team members to bring up potentially confrontational issues in a setting that allows us to speak about them openly. I’ve worked with several teams previously that had issues that were detrimental to the daily operation of the team, and could have easily been fixed with a conversation. I encourage everyone to keep their items to a sentence or two in length, and that allows the items brought up to be straight and to the point. This format of retrospective allows everyone to contribute equally, and helps more reserved members of a team to voice their concerns.
Since we started performing retrospectives in this fashion, we have began pair programming, added patch versions to our user stories, and even helped remote members of our team feel more included. Everyone on the team also feels like their opinion has more weight, which has improved team morale. All of these little things have lead to a huge improvement of productivity and code quality.
The sprint retrospective process has allowed everyone on the team to have a voice in fundamental changes in how we work. One side effect to this is it also brings everyone closer as a team, and ensures that all team members have voiced concerns with issues that may have been irritating them over the past few weeks. As a result, the team has a collective idea of what the concerns are and how to address them. I encourage you to give the retrospective model i’ve described with your team and see what your team has to say. The first few times, you may be surprised with what your team has to say!
If you have additional questions for me about how we perform retrospectives, feel free to leave a comment below.