Retrospectives 2 - Perhaps Your Best Source of Valuable Improvement Ideas

Countless times I've been in three types of discussions that rekindle my interest and action in establishing a periodic discussion of a team's operation and performance, guided by the team itself without management involvement:

1. "Everything is just fine . . .  or is it?" Over lunch one day I discovered, to my surprise, that the project team members had widely varying views about our project - the project leaders thought things were just fine, while others on the team were vocal in expressing the need for changes to rectify serious issues.  It became obvious to all of us that nothing was going to happen (to improve) unless there was some degree of agreement that there were, indeed, project issues that required fixes.  This lunch afforded us the opportunity to check in with one another on how we felt about the project operation, and as a one-time event it was rather effective.  The team just needed to have a forum for identifying and working together on improvements.
2. "I'm fine, but others are the problem." While waiting for a status meeting to start, several of us had a chat about some of the recent project difficulties.  Here is what the project manager and a few team leaders had to say: "our core project team is doing very well, but the partnering departments are causing all of the problems."  A focus on blaming others is never pretty and signals a reluctance to consider our own contribution and performance.  Without a forum that emphasizes project team introspection, it can be too easy to slip into criticism of others and miss an opportunity to understand those areas where the project team itself can improve its own performance.
3. Team members: a source of the best improvement ideas. What started as a "how was your weekend?" chat gradually morphed into an impromptu 10-minute hallway discussion where I listened as project team members spontaneously listed a half-dozen terrific ideas on how things could be performed more efficiently on their current project.  Make no mistake about it: your project team members have many improvement suggestions, but these jewels will likely be lost forever if there is no mechanism for collecting, discussing and incorporating them into the team's operation.

While those three conversations happened on projects, years ago, they reflect sentiments I still hear quite frequently. Today, these don't need to be hallway conversations or a private direct message that never reaches the whole team; the retrospective gives them a natural forum.

Teams that are good at evaluating their own strengths and shortcomings build a confidence in their ability to perform.  They are continuously improving, and the value delivered to their customer will also increase as improvements are implemented and become integral to their team's operation.  They have no reason to ever fear any outside evaluation, because they are already addressing any issues that an outsider might identify.

Assessing Your Team's Focus on Team-Based Continuous Improvement

How do self-evaluations occur on many teams? Sadly, many organizations have no mechanism for capturing a team's evaluation of its own work and using it to shape the next sprint or the next project. Worse yet, an organization may invest in collecting insights from team members but fail to apply this wisdom.

Think about your most recently completed sprint and the steps you and your teammates are taking to improve performance in the next one. Score your attention to continuous improvement by counting the statements that apply:

1. At the start of the sprint:
   • We reviewed the improvement actions chosen at the last retrospective.
   • We reserved team capacity in the sprint plan to carry them out.
2. During the sprint:
   • We completed the planned improvement actions, and were certain to complete the important ones.
   • We kept a running list (a chat channel, a column on the board) where anyone could post observations and suggestions about how the sprint was going.
3. At the retrospective:
   • We reviewed data on the sprint, not just impressions.
   • We validated the benefit of previously implemented changes.
   • We identified and agreed on just a few changes for the next sprint.
   • We launched a closer look at any area where improvement is clearly needed but no obvious action has surfaced.
   • We kept our focus on changes the team itself could implement, rather than changes we'd need someone else to make.

Your score on this is an indicator of the degree to which continuous improvement is an integral element of your team's routine. Higher scores suggest an emphasis on continuous improvement. If you answered "yes" to only a few of these, you may not be taking advantage of the knowledge, experience and wisdom of the team members, and that may be limiting your potential for improving team performance.

I've used three distinct methods for assembling information about a completed project and creating suggestions for future projects: post mortems, lessons learned and retrospectives (and have written a few notes about these in the first article of this series). By any name, this particular type of activity will focus on listing a few things that went well and some that were problematic. Most will even identify a couple of changes for the team to implement next time.

This article, and the others in the series, is about the retrospective. The technique is applicable to any framework that delivers in iterations or cycles.  Retrospectives are widely incorporated:  Scrum time-boxes it as the Sprint Retrospective, XP and SAFe have their own versions, and the Agile Manifesto's 12th principle is the one-sentence version that predates all of them. Two books define the practice for me. Norm Kerth's Project Retrospectives (2001) gave us the term "retrospective."  Esther Derby and Diana Larsen's Agile Retrospectives, now in a 2024 second edition with David Horowitz, gives us the 5-step meeting that many teams run today (the 2006 original introduced it), and that the fourth article in this series walks through. If your team runs Scrum, check out the Sprint Retrospective paragraphs of the Scrum Guide as well; they are a two-minute read.

What Good can Come From Retrospectives?  (A lot!)

Retrospectives can be monumentally beneficial to a team and its work . . . if team members understand the potential advantages and participate with an attitude of achieving them. Here are the key results when a team fully adopts retrospectives; think of these as objectives for your retrospectives:

1. Team Dynamics - The team members work more effectively together
   • Culture: The team develops its own values and principles that are specific to the way they choose to improve their performance.  Most teams (unknowingly) embrace Norm Kerth's Prime Directive: regardless of what we discover, everyone did the best job they could, given what they knew at the time.
   • Open Dialog: It is a natural forum for open discussion where team members share perspectives, perhaps sharing insights not previously considered. This is the time to constructively expose frustrations and disappointments that need to be addressed. Google studied its own teams to find out what distinguishes the effective ones, and psychological safety, the shared belief that it's safe to speak up, came out on top.  And a natural forum for practicing this is in every sprint retrospective.
   • Closure: A retrospective at the end of a sprint, or of a project, is an element of bringing closure to that cycle and moving on to the next.
   • Teamwork: This activity reinforces the importance of working together as a team and determining how to best prepare for the next sprint.
2. Team's Ownership - The team is committed to improve their performance
   • Responsibility: Reinforces the team's obligation to manage and improve their processes, methods and skills of the team.
   • Accountability: The actions of the retrospective enable the team to take action and be accountable for improving its performance.
3. Performance Evaluation - The team has a common, shared view of how the sprint went
   • Strengths: Reinforces longstanding and new practices that contribute to the team's efficiency and effectiveness.
   • Assessing past changes: Gives a natural forum for evaluating newly introduced practices - Are they working as intended? Are they accepted by team members?
   • Agreeing on current concerns: Identifies problem areas that need attention.
4. Improvement - The team has an agreed focus and approach to make specific changes that will improve performance
   • Institutionalizes Improvements.  Assets (e.g., training materials, processes, the team's working agreements) are updated and revised based upon experience and needs.
   • Agreed Actions:  The team has a shared view of improvement steps to take.
   • Improved Performance:  Through evaluation, discussion and action, the team actually achieves improved performance, addressing disappointments and frustrations.

What's Next?

Many teams miss out on an important opportunity to improve. When a project completes, the team celebrates their success, and everyone runs off to the next project.  When a sprint ends, there's no celebration or exiting to a new start elsewhere.  Typically, the team shows its sprint accomplishments and it's on to the next sprint on Monday.  Nothing has changed.  It's a missed opportunity, and the insights and new knowledge developed along the way will wither over time without a significant, lasting impact in the organization.

There is an alternative: study, understand and run retrospectives in every sprint and at the end of every release. This mechanism, when implemented effectively, can build stronger teams and yield sustained team performance improvements.

The next step in this journey is becoming familiar with various retrospective meeting formats and approaches, presented in the third article of this series, Foundations for the Perfect Retrospective.