With all of the expert materials readily available, you might assume that retrospectives are universally adopted and yielding benefits daily. Unfortunately, that isn't the case.

Oftentimes, the impact of the retrospective technique is somewhat underwhelming.  Even disappointing.  I frequently find teams that have no retrospective activities, and I rarely encounter a project team that is actively making use of lessons that have been "learned" from prior projects.  They might be documenting their own lessons, but don't seem to have a mechanism for using that type of information from preceding projects or assuring that today's lessons will be used on later projects.

A second problem shows up a few months after a team introduces retrospective meetings. The first few retrospectives are lively and energetic.  And impactful: they produce real change. Over time the meeting settles into a stale routine with the same format, the same 3 complaints, and an unused action list of changes to be made. The team is conducting retrospectives, so that can be checked off as completed, but improvement is not to be found. Most of the tips below are aimed at that second problem as much as the first.  (For a PMO that got both problems right, see PMI's case study of retrospectives at Intel.)

Many books and articles describe how to execute effective retrospective meetings.  Before we get to that topic (in Retrospectives 4 - The Perfect Retrospective), let's look at how to adopt retrospectives and create an environment that promotes and supports continuously improving team performance:

1. Bringing Retrospectives into first use
   1. Introduce Retrospectives to the team.  Before you even start retrospective training sessions (let alone conducting the first retrospective) you'll want the team to be aware of the benefits, choices they'll be making in selecting or defining their retrospective techniques, and expectations that they (and others) will have about the outcomes of retrospective activities.
   2. Educate and Train the team and management.  It may be overambitious to assume that convening a set of people (who are unfamiliar with retrospectives) will naturally and consistent yield positive results.  Invest in educating the team and others about the value of continuous improvement, followed by training on specific retrospective techniques and how to apply those techniques in your environment.  These are important enabling actions.  Soft skills training is also helpful.  Retrospective activities are filled with interactions which could potentially be interpreted as criticism or blaming; team members and managers need to be properly prepared with skills for effectively participating and contributing in such situations.
   3. Retrospectives for every cycle.  Incorporate retrospectives into your organization's culture so that it is naturally expected that every cycle, and every project, will have a retrospective with valuable results.
   4. Ensure Role Clarity and Accountability.  In the old days of post mortems, only one person needed to be knowledgeable and skilled in the technique.  In the world of retrospectives, many roles must all contribute to achieve consistent and sustained benefits from retrospectives.  Here's a possible delineation of roles for which people should be trained and adequately prepared:
      1. Manager: create an environment that enables (and expects) retrospectives
      2. Coach: initial training on the method
      3. Team lead or Scrum Master: ongoing training and facilitation
      4. Team Member: active participation
2. Conducting Retrospectives Every Cycle
   1. Always Use Data.  It's unfortunate that while many web sites focus on various methods of soliciting opinions during a retrospective, few stress the requirement for data.  Don't make that mistake.  Ensure that your chosen retrospective method always includes pre-workshop activities for collecting data that will be the basis for coming to a common understanding of performance and the subsequent analysis and discussion. (Otherwise, your retrospective just becomes a "talk show" where opinions abound - and every opinion, well-founded or not, carries equal weight).
   2. Continuous Collection of Data and Observations.  Even in a cycle of only a couple of weeks, it can be easy to forget a key observation when it comes time for the retrospective meeting. Consider keeping a place (a chat channel, a column on the board) where observations can be recorded in real-time, for further discussion during the retrospective meeting.
   3. Define Success.   Define the measures of a successful cycle (and a successful release) before even starting and then evaluate it, using data, against those criteria.
   4. Retrospective of Retrospectives.  Periodically conduct a retrospective on the retrospective process itself. Continuously improve at improving! Usually, the focus of your retrospective is the most recently completed cycle. Periodically, introduce a trending retrospective that seeks to examine the performance trends of your team over time. I also recommend using these retrospectives to evaluate the value delivered to the customer over time.  This practice is also the best defense against the retrospective going stale.
3. Continuously Improving through identified actions
   1. Maximizing your retrospective's results. Ensure that the output of your project retrospective is shared and your newly acquired wisdom is applied to other teams and future work - but this doesn't mean publishing a retrospective review document that everyone must read.  Nearly every retrospective I've encountered results in an action item list for that cycle. At one point my department's 12 agile teams were each completing over 20 retrospectives per year; it just doesn't scale well to have each team publish actions and hope that all subsequent cycles and projects will benefit - no one will take the time, when starting a project, to read through a library of project retrospective documents and incorporate all of the learnings into this new project.  Construct your retrospective action items so they contribute to the knowledge base of your organization - generally speaking, your actions should be creating or improving: job aids, processes, training materials, job or role definitions, along with improving skills and knowledge (by training team members & management).  Resist taking the easy path with "one-off" improvement actions that are unlikely to have any sustained improvement impact.
   2. Tracking Completion of Improvement Actions.  For any team that works from a backlog, there's no need to create a special mechanism for recording and tracking improvement action items - create a backlog of "team improvement" items and use your standard planning and delivery processes for selecting from that backlog, completing them, and reviewing the result. And reserve capacity in the next cycle for them; an action with no time allotted is merely a wish.
   3. Viability and Impact of Improvement Actions.  A common consideration in constructing retrospective actions is to ask "who is in control."  That is, for a particular impediment, who controls the ability to improve in that area; typically the choices are "the team" or "management." (The self-assessment in the previous article makes the same point: keep the focus on changes the team itself can make.) Two additional factors should also be considered:  1) Impact: how important is this action?  If it is fully addressed, will it significantly improve our performance; and 2) Viability: how possible is it to accomplish this identified action.  You'll want to be choosing actions that have high impact and are reasonably viable.

What's Next?