This is the first article in a series about retrospectives.  The series includes:

1. Retrospectives 1 - Examining Sprint Performance and Learning From the Team's Experience - that's this article.  A short recap of quality management and continuous improvement, starting with Shewhart and Deming, leading to retrospectives.
2. Perhaps Your Best Source of Valuable Improvement Ideas builds a compelling case for adopting retrospectives as a primary method for improving team performance.
3. Foundations for the Perfect Retrospective gives pointers to some great information on retrospectives and gives almost a dozen tips on successfully establishing retrospectives in your organization.
4. The Perfect Project Retrospective outlines your activities (pre-, during, and post-retrospective) for a constructive and effective retrospective.

Summary

Shewhart first described a method for monitoring the quality of a work product in a factory setting.   (I've not found anything that predates the work of Shewhart and his work is the first that I learned, so let's use his work as the starting point.)  Shewhart described a three step process of Specification, Production and Inspection.  He introduced the innovation of using statistical analysis of product inspection results to continually revise product specifications and the production process. This is the genesis of thought on continuous improvement.

Shewhart essentially gives us a framework for understanding the quality of a produced item and using that information to revise product specifications.  At first glance, this almost seems too obvious.  Perhaps, but disappointingly, not universally applied.  Consider your own experience on software teams: just how frequently have you seen the quality of your software system measured, with those results then being used to revise the software process?  Were he in the room with you, Shewhart would ask to see your data and want to know what you did about them.

Shewhart's model became the foundation for the next innovation brought to us about a decade later by W. Edwards Deming.

Principles for Improving Quality - Deming

Deming further developed Shewhart's concepts into a four-step process that describes introducing an improvement and then evaluating the effectiveness of that change.  (This version of his diagram is from Dr. Deming's 1982 book Out of the Crisis, p. 88. The W. Edwards Deming Institute still teaches the cycle today, as PDSA.)

Deming's innovation was to methodically plan improvements.  After selecting an improvement action and bringing it into implementation, study the results - looking for the impact of the change and learning from these results.  This cycle was called the "Shewhart Cycle" by Deming himself.

A Simplified Model for Improving Quality - Deming along with Japan's Business Leaders

Deming's four-step "Shewhart Cycle" while logical, was not sufficiently memorable.  Fortunately a major simplification has become very well known over the past 75 years.

Deming visited Japan in 1950 and presented his quality models to a large assembly of engineers and managers during an 8-day JUSE seminar.  During this visit to Japan, he also met with the presidents of Japan's largest companies (Described in Deming: The Way We Knew Him, Page 138) at the Mt. Hakone Conference center - during these meetings Deming described a continuous cycle of Design-Manufacture-Sale-Investigative Survey, and he represented this as "The Deming Wheel."  

Shortly afterwards, the concise Plan-Do-Check-Act concepts were conceived, probably by Japanese business leaders, as a simplification to Deming's concepts.   In What Is Total Quality Control?: The Japanese Way, quality expert Kaoru Ishikawa (inventor of the fishbone diagram) presents this version of the Plan-Do-Check-Act wheel in the context of Deming's 1950 visit to Japan:

Plan-Do-Check-Act (PDCA) has become a well-known approach to quality improvement.  It is universally known as both the Deming Cycle and the Shewhart Cycle.

(In The Deming Seminar, which I attended in 1986, Deming distanced himself from PDCA, having come to the perspective that check was a significant understatement of the actual activity.  He recast the wheel as Plan, Do, Study, Act (PDSA), with the change of emphasis to studying the impact of the change vs. merely checking on the change.  While PDSA is a more accurate description of the method, it never received the same attention, thus it has not been as widely recognized as PDCA.  Moen and Norman have a fascinating paper on the creation and modification of PDCA through the years).

PDCA was conceived in the 1950s, well before software projects were common.  Applying PDCA as a regular sprint activity is a natural fit: plan the sprint, do the work, check the result, act on what you learned.  This is a direct application of the Agile Manifesto's 12th principle ("At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.")  Deming would recognize this practice in a heartbeat.

Evaluating and Improving Team Performance - the Journey to Retrospectives

Innovators of previous decades provided us with a terrific foundation for quality control and continuous improvement. A later generation (Alistair Cockburn, Norm Kerth, Esther Derby and Diana Larsen) gave us practical methods implementing the Shewhart Cycle and PDCA as retrospectives that a team can run on its own.  Here's what I've experienced in my journey from my first post mortem to the sprint retrospectives I support today.

The Formal Project Post Mortem - Why did this project fail?

Our initial attempt at understanding project performance is a method, probably still in use, called post mortems.  It's an unfortunate term, with many negative connotations and openings for dark humor; it's even confusing to spell (one word? two? two with a hyphen?).  A post mortem is generally conducted at the conclusion of a large project that experienced notable problems - project problems so significant that a company executive really wanted to know what went wrong.  Quite frequently, it is led by an outsider, a person not connected with the project.  I've seen that the focus is largely on the triple constraint areas (cost, scope and schedule).

Using just about any definition or description you could find of a formal project post mortem, you would logically conclude that the goals are reasonable and the methods appear to be sound. It is hard to argue against the value of assembling project data, interviewing people and validating opinions, performing an extensive root cause analysis, identifying fixes and issuing a final report. The difficulty is this: the project post mortem has a tarnished reputation that serves to diminish any enthusiasm that participants might have for the activity. Try this experiment: ask a handful of your colleagues to tell you the first thing that comes to mind when you mention the term "project post mortem" and see if any of these are mentioned:

1. The only reason for conducting a post mortem is because a project has failed.
2. The primary purpose of a project post mortem is to satisfy upper management's need for a report on the project failure, not to drive improvement
3. Few people expect the results to actually contribute to advancing the project maturity of the organization.
4. More likely than not, the post mortem will identify a guilty party, pointing blame to an individual or group.

I first participated in project post mortems in the early 1980s, and conducted my final project post mortem in 2003. Most were at the conclusion of a troubled or failed project. Through this period, I observed a declining interest by participants because they had little confidence that goals of a post mortem would actually be achieved; it seems that my observations are in line with the experience of others.  Nevertheless, the project post mortem was a very good first step aimed at learning from a project experience and using that information to help other projects.

Enter the site reliability engineers!  John Allspaw at Etsy wrote up the idea in 2012, and Google made it standard practice in its 2016 SRE book to conduct a "blameless postmortem" after every serious production incident.  (They also settled the spelling: one word. Well, almost. Allspaw wrote "PostMortems" and Google writes "postmortem," so the argument continues, just with fewer options.)  This new form of postmortems was a significant improvement, with written rules: the assumption that everyone involved acted in good faith, a focus on fixing the system rather than the person, no naming of (presumed) culprits. Read those rules next to the 4 complaints above and you can see what was wrong with our old post mortems. The inherent blaming that became routine, it turns out, was the problem all along.

Project Lessons Learned - How did you feel about the project?

The emergence of "Lessons Learned" appears to me to be a direct response to some of the criticisms of project post mortems.  The new name is clearly a step in the right direction - most people resonate with the positive implication of "learning and improving."

Lessons learned sessions tend to use less hard data, instead relying upon opinions of team members. Here the focus is on the team's view of how well they followed their process and performed together.  A typical Lessons Learned Questionnaire is peppered with "how effective . . ."  "how well did . . . " and "how did you feel about . . ." questions.  Lots of opinion, a bit light on data (e.g., performance relative to the triple constraint or on delivered business value).

The lessons learned activities that I've led or in which I participated were very different from project post mortems;  much more upbeat, conducted for all projects (not only troubled or failed projects), and the team itself was the primary consumer of the results.  They were timely, fast, inexpensive to conduct, led/facilitated by a project manager, focused more on opinion and less on project data, and were driven by questionnaire responses that were completed by project participants.  If a lessons learned meeting was conducted, then the team had an opportunity to discuss their responses to the questionnaire and collaborate on identifying improvement actions.  If this meeting was not part of the process, then the burden almost always fell to the project manager to interpret the questionnaire responses and determine the path forward.

Overall, I've found lessons learned activities fairly effective in getting participation by most team members, but no more effective than post mortems in driving lasting and sustained improvement.

Retrospectives - What wisdom did we gain and how can we best apply it going forward?

The latest turn on our journey of evaluating and improving team performance is the retrospective. Alistair Cockburn described working in increments (way back in 1997) and in 2001 he wrote up the "reflection workshop" in Agile Software Development. Also in 2001, Norm Kerth put the term on a book cover with Project Retrospectives. And the Agile Manifesto, also 2001 (this was a banner year for innovating in new team practices!), put the practice into one of its 12 principles. The definitive implementation reference is Agile Retrospectives, Second Edition (2024), by Esther Derby and Diana Larsen with David Horowitz, an update of the 2006 original that introduced the repeatable 5-step meeting. Most teams operating in iterations incorporate reflection and improvement discussions (Scrum time-boxes it; XP and SAFe have their own versions).

The name has a connotation of deep thought and introspection, perhaps sprinkled with a smidgen of reminiscing. It sets a tone of constructively congregating and jointly examining the work. Retrospectives are about the shared experience and the collective learning and wisdom gained by the team members. Of course, all of this intellectual activity is accompanied by focused action that results in improvement. That depth of examination differentiates a retrospective from a lessons learned survey.

The sprint retrospective is conducted by the team itself (some inexperienced teams elect to have a coach or outside facilitator run the meeting, but the improvement actions are still the team's) - this is an important innovation. This improvement mechanism is not driven by an outside consultant or management; rather it is an instance of the team taking responsibility for improvement. This distributes responsibility and accountability throughout the organization, not just limiting that task to management or a project manager.

Integrating sprints and retrospectives creates the perfect petri dish for continuous improvement. Short, frequently executed cycles with a built-in examination of performance at the conclusion of each one create a situation in which a team can continuously observe, plan improvement actions, complete those actions, verify the impact of the improvement, and respond appropriately - this sounds remarkably like PDCA!  Shewhart, Deming and Ishikawa surely would have high words of praise for any team that adopts this approach.

As with post mortems and lessons learned, there are many varieties of retrospectives and techniques (more about these in the next article). The best retrospectives make use of quantitative data as well as team member observation and opinion. The team does need to develop a discipline in selecting improvement actions to maximize impact.

Sprint retrospectives scale very well as a primary means of continuous improvement - with responsibility distributed to the teams doing the work, there's no single constraint that limits the potential for improvement. With everyone on the team participating, the opportunity for identifying the best improvement actions is maximized. Of course, retrospectives have many other benefits and advantages.

The traditional end-of-project (or end-of-release) retrospective still has a place. A sequence of many sprints prior to release may not produce an accurate view of how well the team's delivery satisfies the customer's need, and that view matters more every year. Kerth's book covers that longer, deeper form well.

What's Next?

There's always opportunity for a bit of improvement; the trick is tapping into facts, observations, opinions and insights of team members to understand that opportunity. Across 4 decades we've used post mortems, lessons learned and retrospectives - of these, the sprint retrospective has proven the most effective, especially for smaller teams that meet often.

It turns out that Walter Shewhart didn't invent the sprint retrospective, but he certainly started us in that direction with his work on using statistical analysis of manufacturing to understand factory production performance; Deming and several of Japan's influential thought leaders took us further down the continuous improvement road with Plan-Do-Check-Act. The sprint retrospective is PDCA with the sprint as its clock.

The next article in this series, Perhaps Your Best Source of Valuable Improvement Ideas, explains the most significant reasons for adopting retrospectives.