Effective Sprint Retrospectives

Sprint Retrospective Meetings have a simple intent: To discover, discuss, and take note of tangible process improvement opportunities.

A Sprint Retrospective is essentially a process improvement meeting at the end of each sprint where the Agile / Scrum team discusses what went well, what should change, and how to implement any changes.

Simple Rules

1.      The Scrum Master acts as the meeting facilitator

2.      The Sprint Retrospective scope if focused on the last sprint

3.      Meeting participants include:

• Scrum Master
• Product Owner
• Development Team
• If agreed to by the team it is possible to have other participants, such as customers or other stakeholders, but that is entirely up to the team to decide

4.      During the Sprint Retrospective, the team focuses on the essential 3 questions:

• What went well?
• What would we like to change?
• How can we implement that change?

5.   The key to making a Sprint Retrospective useful is to keep it “action focused” – meaning the team needs to focus in on what they can change to make their own process better

6.   The meeting time is fixed: 45 minutes for each week of sprint duration

Managing Process Improvements over Time

As mentioned, the Sprint Retrospectives should be action focused – the intent is to rapidly improve upon the process in order to enable better productivity.

But, the reality is that some improvement suggestions might be quickly addressed, some might take some time, and others might be outside of the teams’ area of decision power.

It is suggested to keep a running log of improvement suggestions that will help you keep track of what improvement ideas came up, what category they fall into, and what sprint / release they first came up in, etc.

This helps keep the team accountable and ensures you remember all the process improvements you implemented over time.

The time frames that some improvement suggestions fall into are as follows:

Within the Next Sprint

An improvement suggestion that can be accomplished over the course of the next sprint, for example, refactoring of a specific web service interface. Quit hits, quick successes.

Over Several Sprints

Improvements that might take two or more sprints to implement. Re-architecting subsystems, or a comprehensive UI update, tasks that cannot be finished in one sprint, fall into this category.

Over the Next Release

Infrastructure refresh efforts, such as switching continuous integration (CI) tools / environments, might fall into this category. Something that you coordinate by release so you do not interrupt the delivery flow of your sprints.

Never

Yes, I know some people do not like the idea that some improvement suggestions will never be addressed, but we all know situations like this. Say, for example, you are working on a huge legacy system written in Java/Linux, totaling 3 million lines of code. And the improvement suggestion is to rewrite the entire system in C#/Windows.

This is an improvement suggestion that falls into the “Never” category; not because it might never happen, but because it is a decision in terms of impact and scope that cannot be decided upon by the team.

Common Challenges and How to Deal with Them

Boiling the Ocean

It is incumbent on the Scrum Master to keep the team on track during Sprint Retrospectives. Sometimes teams have a tendency to focus in on problems that fall into the “Boiling the Ocean” category.

Those are sometimes great discussion topics (especially for a long night over a couple of beers), but they almost always fall outside of the scope and sphere of influence of the team.

In order to make sure that the Sprint Retrospective is useful and produces good improvement suggestions, the team should avoid these kinds of discussion topics and focus on two parameters to guide the discussion

1. Is the improvement suggestion relevant to the scope (last sprint / current release)?
2. Is the improvement suggestion achievable by the team?

Non-Participation

Several years ago a team member refused to participate in a Sprint Retrospective. When I asked him why, he said “Sprint Retrospectives are supposed to be like Lessons Learned meetings… but we never learn any lessons, we still got the same issues we had 2 years ago, so why waste time?”

His point was completely valid. To make Sprint Retrospectives work, you need to focus on what is relevant (last sprint / current release) and what your team can actually implement. Keeping track in a log as to what improvement suggestions were brought up, which ones got implemented, etc. keeps the team accountable but also shows the progress.

Blame Game

Improvement suggestions should never smell like blame is being assigned. It is important to have open team communication, and to honestly assess what can be improved upon by the team. Be careful not to assign blame but rather focus on potential solutions.

Everything is Great / Bad Attitude

Beware of both, irrational exuberance, and downtrodden doomsday forecasts. Both extremes are usually unrealistic. You can always improve on the process, and things are never as bad as some folks might make them seem.

No Improvement from Last Retrospective

Once again, track what you want to improve on, and if it is within the scope of one sprint, put it into the backlog for the next sprint.

As a general guidance, I try to reserve up to 20% of capacity in early sprints for process improvements. In later sprints that might go down to 10%. Point here is that you have to account for this work. It is not going to happen by itself, or in addition to an already fully utilized team.

Process improvement activities are part of the sprint activities, not in addition to it.