Agile Advisor

Retrospective Meetings: Agile Learning from the Past

Aaron Bjork talks about the power of learning from the past and gives some insight into how to get the most out of your retrospectives in your Agile projects.

• By Aaron Bjork
• 05/23/2011

Most of us apply "learning from the past" in our daily lives without realizing it. It only takes a few times being stuck in rush-hour traffic for me to adjust my departure time from work. I value my time, and I have learned from the past that I can significantly decrease my commute time with a simple change to my schedule. By "looking back", we learn how to avoid past mistakes, and repeat successes. This is a relatively simple concept, but one that often is more difficult to put into practice in the real world... or in real organizations.

Retrospective meetings have been commonplace in software development teams for many years. Teams hold a meeting at the end of a project or milestone to discuss successes and failures, and then look for ways to create more success and less failure in future projects or milestones.

Agile teams in particular have embraced retrospectives as a way to drive continuous improvement into both teams and processes. As stated in one of the twelve principles behind the Agile Manifesto, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." In this month's column, I want to dissect this principle and examine a few key elements of effective retrospectives.

Regular Intervals
The first key statement in the principle is about regularity of reflection. The principle states upfront that a team will reflect on being more effective at regular intervals. If the team "looks back" at random times in the product cycle, or only at the end of a long release, the value of any learning from the retrospective is diminished. I have participated in numerous retrospectives at the end of long release cycles that achieved nothing more than the creation of a long list of items that everyone wishes we had done differently (I'm sure you have these hanging in your offices as well).

The problem with this type of reflection is that the scope is so large and so broad that very little of the learning is actionable. In contrast, regular time for reflection helps to establish an environment of natural continuous improvement.

Scrum prescribes that teams perform retrospectives at the end of every sprint. The idea is to instill in the team that "becoming more effective" is a natural part of the team's behavior. Whether the sprint is one week long, or four weeks long, the team reflects at the end of the sprint on how it can become more effective.

Tune and Adjust
The second statement in the principle is a clear action item for the team -- the team will tune and adjust. It does not say the team will start over, and it does not say the team will experiment or radically change its approach. These two words (tune and adjust) have particular significance because they imply a precise set of actions.

If you have a music background, you know that tuning an instrument takes a well-trained ear. It is a precise action. You tune with precise movements and careful actions to ensure that the instrument produces the required pitches. To this end, a retrospective should produce a set of precise changes for the team. A retrospective should not result in drastic action that fundamentally changes how the team operates. Too much change, or too big of a change, will only disrupt the team and get in the way of producing value for the customer.

Team Behavior
Finally, and perhaps most important, the last few words in the principles states that the team will tune and adjust its behavior. It says nothing of the behavior of other teams; it says nothing of the behavior of the organization as a whole; and it says nothing of the behavior of anyone outside the team. This is a statement of personal responsibility. The team changes its own behavior.

Be careful to avoid identifying all the external problems to your team. It is easy to blame poor execution on factors outside the control of the team. There is benefit to understanding those factors, but a common trap many teams fall into is blaming all their difficulties on those around them. Be sure to keep the retrospective focused on those things that are within the team's control.

Retrospectives are invaluable to creating high functioning teams and organizations. As your teams "look back" over the past, be sure to establish a regular cadence for reflection, be sure to tune and adjust where necessary, and be sure that you are identifying and improving things within your team's control.