AmbySoft.com

Ambysoft Logo

Disciplined Retrospectives: How To Gain The Promised Benefits

Retrospectives are a technique pioneered by Norm Kerth that enable teams to identify “lessons learned.” Disciplined retrospectives extend the technique of retrospectives to address the complete improvement lifecycle, including acting on any identified improvement opportunities, measuring them, and giving improvements long enough to take hold.

Figure 1 below overviews the overall retrospective-based improvement process. There are several iterative steps:

  1. Plan retrospective. Unless your retrospective is impromptu, you will want to plan it. This includes identifying who you would like to invite and when and where you intend to hold it.
  2. Hold retrospective session. A retrospective is a facilitated discussion with the goal of identifying potential improvements for your team. See holding disciplined retrospectives.
  3. Act on improvement suggestions. A lesson isn’t learned until you act on it. See acting on improvement recommendations.
  4. Measure results. As Lord Kelvin opined, “You can’t measure it you can’t improve it.” See measuring results.

Figure 1. The disciplined retrospective process (click to enlarge).The process of disciplined retrospectives.

 

Holding Disciplined Retrospectives

Retrospectives are a common agile strategyDisciplined retrospectives:

  1. Are focused. A team holds a retrospective to identify potential issues with the way that it has been working together, in what it has produced, or in how it is working with other people and teams external to it. This is not a status meeting. This is not just a complaint session (although describing problems may come close to complaining). This is not an opportunity for the team to horse around.
  2. Are facilitated. Retrospectives, like many working sessions, should be facilitated by someone experienced in doing so. There is a lot of great advice around running retrospectives, see the recommended resources at the bottom of the page.
  3. Leverage advice from experts. You want to identify issues and potential courses of action to address those issues. Although there is much rhetoric around “the wisdom of crowds,” the fact is that you’re better advised to seek the advice from someone with experience in a similar problem to what you’re facing. There are several ways that you can do so: seek the advice of an experienced coach, seek the advice of an experienced colleague, seek advice from an AI-based chatbot (be careful), do some research into the problem that you face, or leverage the advice from a knowledge base such as the Disciplined Agile toolkit.
  4. Are held at the most responsible moment. It is tempting to schedule retrospectives on a repeating cadence, for example the typical strategy of Scrum teams is to hold retrospectives at the end of each sprint (they even call them “sprint retrospectives” FFS). While this is better than waiting until the end of a project, or after a release, it is still questionable. A better strategy is to hold retrospectives when you need to do so, a lean way of thinking rather than a Scrum or project way of thinking. If you’re suffering from a problem right now, why don’t you explore it right now so that you could identify a potential solution and implement it now? Why suffer with the problem until the end of a sprint, or end of a project?
  5. Produce actionable recommendations. You may not always achieve this, sometimes the only viable solutions can’t be acted on right away due to lack of time, expertise, or funding. But usually you should be able to identify potential actions to experiment with that are likely to address the issue(s) that you’ve identified.

 

Acting on the Improvement Recommendations

A lesson isn’t “learned” until you act on it. This is where undisciplined approaches, which unfortunately seem to be what the majority of teams follow, tend to fall down. With a disciplined approach to retrospectives how you act afterwards is just as important as how you act during the retrospective. My advice is to:

  1. Focus on just a few improvements at a time. You only have so much capacity to experiment with changes to your way of working (WoW). Focus on the potential changes that will offer the most meaningful changes for your team and ensure that the changes have been truly adopted (see Measuring Results) before moving on to new changes.
  2. Get help to make the improvements. Just like it makes sense to get advice from someone experienced in the problem(s) that you’re facing, it makes sense to get help in making the proposed changes that you’re experimenting with.

 

Measuring Results

Your team has invested time and effort into making potential improvements. But have you actually improved? By how much? Are the improvements sticking? My advice is to:

  1. Measure your potential improvements. You want to determine whether or not the changes that you’ve made to your WoW have resulted in the improvement you were hoping for. Before making a change, first identify how you will know that your desired improvements have been achieved. In effect, identify what you need to measure. Then take those measures so that you have a baseline from which to judge. Over time, as you adopt your identified changes, continue taking these measures. Are you improving? Staying stable? Deteriorating?
  2. Continue measuring for several months after you believe you’ve succeeded. A common mistake that teams make when trying to improve their WoW is to declare success to early. They’ve been working hard to adopt the new WoW, their metrics are showing improvement, and they’ve identified new problems that they want to focus on solving. So they shift their focus to the new issues, only to see themselves slip back into their old WoW. The problem is that it takes time to make new WoW stick, usually longer than you think. What you want to do is to continue focusing on the supporting the new WoW for at least several weeks, and better yet several months, after your metrics show that your improvement from that new WoW has peaked. This takes discipline. This concept is called “measured improvement” and is depicted in Figure 2 below. This strategy was developed at IBM around the 2006-2008 timeframe after extensive research.
  3. Keep the detailed measurements to yourself. The measurements that you take are for the team, not for your executives. I hope that they’re interested in your improvement efforts and I hope that they support them.  But the metrics that you’re gathering to guide your efforts are for your team and your team alone. Executives will detect any improvements made by your team in the metrics that are being reported to support any KPIs/OKRs applicable to your team.

 

Figure 2. Don’t declare success too early when making improvements (click to enlarge).Measured improvement

 

Common Challenges with Retrospectives

There are several common challenges with retrospectives:

  1. They are perceived as yet another agile ceremony. Many agile teams will hold a “sprint retrospective” as part of their sprint wrap-up efforts. This is a great idea if you’re actively acting on the recommendations coming out of the retrospective, otherwise it’s just another meeting that you automatically hold. This is the danger of putting practices on a regular cadence – you start doing them because the calendar tells you to do them, not because they would add value.
  2. They generate lessons indicated. A lesson isn’t “learned” until you’ve acted on it, until then it’s merely a lesson indicated.  The point is that you need to look at the entire improvement process, not just the session where you identify challenges and potential solutions.
  3. They turn into complaint sessions. This is particularly true when your retrospectives are just another ceremony.
  4. When treated as a post-mortem they offer little value. A project post-mortem is a retrospective that is performed at the end of a project. The fundamental problem with doing this is that at the end of the project there is no longer any opportunity to act on any lessons indicated. Practice has shown that other project teams rarely seem to leverage the lessons indicated by other teams that have come before them, to their detriment.

 

Further Reading About Retrospectives