A Retrospective on Scrum Retrospectives

A Retrospective on Scrum Retrospectives

October 7, 2021

I recently read Matthew McConaughey's book Green Lights. Like many autobiographies, in some respects it was him performing a retrospective on his life so far. He specifically talked about the good things in his life, calling them "green lights". In detail he described stories about his brothers, parents, friends, roles that he played and eventful times in his life. He was able to do that, look back on 50 years in detail, because he journaled constantly for most of his life. Without his journals documenting his life it might be impossible to do this type of thorough review.

In scrum, a retrospective is performed not at the end of a long project, but at the end of every sprint. It’s the only way to recount what happened in detail for the past 2 weeks. If we waited 6 months or until the end of a long project and called it a post-mortum it might provide lessons learned for the next project, but it would be impossible to recall all that happened – unless all members of the team kept daily journals. Most likely we’d have to recall the “broad strokes” only. Just like when we drive the car and make constant small adjustments by turning the steering wheel as the road gradually bends, the scrum retrospective provides a forum for you to make the minor adjustments to stay on course to completing your overall objectives.

Plus, even if we kept detailed documentation of everything that happened as we went for 5 or 6 sprints and then reviewed it, we wouldn’t have had the opportunity to have made adjustments and improvements during that time. Regular retrospectives at the end of each sprint are thus key for teams to continue to improve and increase their velocity, which is how many story points they routinely complete per sprint.

Skipping the retro

However, some ill-advised, busy teams may skip their retro because they don’t value it, probably because they haven’t received value from it. However, this can be an incredible valuable part of a sprint that creates performance improvements for the team. The retro makes things that need to be corrected visible (a pillar of scrum) and allows the team to create solutions that should increase their productivity for every sprint going forward. Solving a few tiny problems every sprint and sometimes solving or working towards solving some big problems can result in a huge accelerator after a year or even a few sprints. But by skipping the retrospective the team loses a key opportunity to improve. By removing this improvement opportunity the team can grow stagnant because problems aren’t going away. They aren’t getting any happier. Small annoying impediments aren’t being talked about.

Teams skip the retro usually for two reasons. Commonly they skip it because they are (1) too busy and/or (2) not getting value from it.

Let’s address the former – being too busy. So all teams are busy. If the team is not busy, they are probably being under-utilized. If a team is “too busy” for their retrospective that means they are being over-worked, which is an indicator of larger problems like not planning out their sprints properly, or not handling injection of new or outside work effectively. Maybe the team doesn’t have a scrum master, or the scrum master isn’t effective or is split between too many teams. These problems need to be addressed. Many times the retrospective is the ideal place to surface these problems and discuss solutions.

The second reason teams skip the retro is because the team may not be getting value from this ceremony. Usually the retrospective is the scrum master’s job to facilitate and ensure it’s effective.

Why some retros don’t generate improvement

In short, lack of, let’s call it, positive-negativity. On a newer scrum team, when developers and testers contribute to their retrospective, there’s an abundance of positive comments. We really rallied when our self-hosted Gitlab account was down for 3 days, way to go! Great job to the team for handling that setback with poise! Or, We had a lot of backlog items go in to testing in the last part of the sprint, but the testing folks did a great job of getting it all tested before the sprint ended. What sometimes fails to get discussed is why did the backlog items not go into testing earlier in the sprint? This would have made testing a lot smoother, and probably more accurate. What if bugs were found while testing multiple backlog items on the last few days of the sprint? Would there be enough time to fix the bugs, go through code review, and then test again? Teams that haven’t matured much are going to focus on the positive that happened during the sprint. This can be a problem because you’re missing why the problem occurred and then formulating a plan to try and improve this in the next sprint.

Mature teams are going to positively and professionally focus on the negative. Professionals will say something like, Jan did a great job of handling testing a lot of stories late in the sprint. We had some big stories that were very complex. How can we give Jan more stories earlier in the sprint so her time is more productive early in the sprint, and stories can be tested and vetted more thoroughly? Then, the brain power of the team usually takes over and solutions for fixing the problem are mined and turned into tasks for the next sprint. Or, they are highlighted somewhere else visible. A good scrum master will remind the team of these things periodically throughout the sprint. Because people are used to avoiding negativity at work, they miss opportunities to improve. The trick is to not obscure the negative in positive light, but to spotlight the negative in a positive light and implement a plan to correct in the next sprint.

Other recommendations for the retro

Hold the retrospective before sprint planning. If sprint planning is done before the retro there may not be space left in the sprint to implement improvements (unless the team specifically reserves space for this during sprint planning).

The length of the retrospective should always be 60 minutes or more. Many, many teams force this down to a 30 minute meeting and always doesn’t allow enough time for productive discussions. 30 minutes is only enough time for a retro if you’re doing it wrong and only focusing on the positive. Its easy for each member of the team to give out thanks and kudos in under 30 minutes. But if you’re thoroughly examining the negative through the lens of positivity and professionalism, 60 minutes should barely be enough time for most teams.

If you have ways that you helped your teams retros be more successful, please share in the comments. Also if you have any other reasons why retros commonly get skipped or don’t produce value, I’d love to hear about them! 😄 Peace ✌️

Retrospective SVG credit Shocho via the Noun Project

Mastering CSS: Book by Rich Finelli
Mastering CSS, the Book! Flexbox, Layout, Animations, Responsive, Retina, and more!
Mastering CSS, 2nd Edition, video course by Rich Finelli
Mastering CSS, Second Edition: 47 videos on how to make websites like a boss! Flexbox, Animations, Responsive, Retina, and more!
Back to top