Tips for Enabling Continuous Improvement by Project Teams
Bill Hoberecht -
Retrospectives are straightforward in purpose and simple to describe, yet most project organizations are unable to achieve even trivial benefits from this immensely important activity. Thought leaders on retrospectives have published a rich set of materials to help project organizations adopt retrospectives - their insights are readily available to help you. You'll also find a few important tips that can establish the foundation in your organization for consistently obtaining the best results from your investment in retrospective activities.
Introducing A Series of Articles on the Perfect Retrospective
This is the third article in a series about project retrospectives. The series includes:
- Examining Project Performance and Learning From the Project Experience. A short recap of quality management and continuous improvement, starting with Shewhart and Deming, leading to retrospectives.
- Project Retrospectives: Perhaps Your Best Source of Valuable Improvement Ideas builds a compelling case for adopting retrospectives as a primary method for improving project performance.
- Foundations for the Perfect Retrospective - that's this article - gives pointers to some great information on retrospectives and gives almost a dozen tips on successfully establishing retrospectives in your organization.
- The Perfect Project Retrospective outlines your activities (pre-, during, and post-retrospective) for a constructive and effective retrospective.
Elements of the Perfect Retrospective
The Project Retrospective - What do the Experts Have to Say?
A project retrospective is an interactive meeting in which project team members participate in guided activities, coming to a common understanding of their project's performance, identifying aspects of the project that stand out as particularly positive or problematic, and planning to institute changes that will improve subsequent projects. The retrospective is held for the practical purpose of fostering continuous improvement. It can serve to strengthen teams.
Scrum calls this a "Sprint Retrospective" (more on this is on www.scrum.org in The Scrum Guide). Others call this a "Heartbeat Retrospective," "Project Retrospective," "Agile Retrospective" or "Event Retrospective." For this article I'll lump these all together and call it a "project retrospective."
In Scrum the Sprint Retrospective activities occur when closing each sprint, generally every few weeks, while other variants of retrospectives occur less frequently. Retrospectives are equally valuable for other project approaches; this technique isn't limited to Scrum and agile projects. A retrospective should cover a "small" duration of work - perhaps a few weeks to a couple of months. Attempting a retrospective for a longer period of time will likely result in faulty recollections, focusing on too few topics, and struggling with too much information to process adequately.
There are thousands of web sites and a few books devoted to the topic of retrospectives. Most of this information is useful and can help you shape your own view of what a retrospective should look like for your projects. Here are a few that are worth a glance to give you some varying opinions on retrospectives. These authors have gone through some deep thinking on retrospectives and they offer valuable insights, approaches and hints.
- My favorite is A Five-Step Approach to Retrospectives in which Esther Derby describes a very good outline for retrospectives. You'll have to look far and wide to find a better starting point. Listen to her 50-minute presentation on retrospectives, glance through her slides for some additional insights, then shell out a few bucks for her book with Diana Larsen Agile Retrospectives: Making Good Teams Great and immerse yourself in the topic. Her simple, straight forward and immediately useful agenda for a retrospective activity is:
- Set the stage
- Gather data
- Generate insights
- Decide what to do
- Close the retrospective
- Project Retrospectives: A Handbook for Team Reviews by Norm Kerth is probably the first book to define retrospectives. Norm's Retrospective Prime Directive puts front and center the important reminder that a retrospective is not to blame or criticize, but to educate. The directive, in its entirety, is: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. Norm also introduced the four key retrospective questionsto guide the retrospective discussion:
- What did we learn?
- What should we do differently next time?
- What did we do well, that if we don’t discuss we might forget?
- What still puzzles us?
- Several consultants have published articles based upon Norm Kerth's book.
- Rachel Davies' How To: Live and Learn with Retrospectives is the probably the clearest, easiest to read summary of Norm's retrospective approach. You may want to watch her presentation Learning from Experience Part II. Her one-hour presentation Rachel Davies - Inspect and Adapt with Agile Retrospectives is also worth watching.
- Steven Rakitin's overview of Project Retrospectives is a good introduction to the topic. As well, he provides a usable agenda of activities for a retrospective meeting. (He continues with Norm's approach of having a 3-day project retrospective, while I am an advocate of a retrospective duration that is much, much shorter).
- Tim Mackinnon summarizes much of Norm's book in this slide presentation.
- The stop/start/continueformat (which can be further enhanced with "do more of/less of") is another good way to frame the retrospective using these questions:
- What worked well last Sprint that we should continue doing?
- What didn’t work well last Sprint that we should stop doing?
- What should we start doing?
- Here's an example of A Retrospective Timeline, and you can find an excellent description in this excerpt from Agile Retrospectives: Making Good Teams Great. The timeline is is a means of organizing project/sprint events, identifying events that can drive a retrospective discussion.
Enabling the Perfect Retrospective
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.
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.
Many books and articles describe how to execute effective retrospective meetings. Before we get to that topic (in Article:Retrospectives 4 - The Perfect Project Retrospectives), let's look at how to adopt retrospectives and create an environment that promotes and supports continuously improving project performance:
- Bringing Retrospectives into first use
- Introduce Retrospectives to the project 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.
- 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 project 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.
- Retrospectives for all Projects. Incorporate retrospectives into your organization's culture so that it is naturally expected that every project will have a retrospective with valuable results.
- 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:
- Manager: create an environment that enables (and expects) retrospectives
- Coach: initial training on the method
- Scrum Master: ongoing training
- Team Member: active participation
- Conducting Retrospectives on a Project
- 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 project data that will be the basis for coming to a common understanding of project 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).
- Continuous Collection of Data and Observations. Even for projects that are only a couple of weeks in duration, it can be easy to forget a key observation when it comes time for the retrospective meeting. Consider having a manual method (a wall for post-it notes) or electronic method (a discussion board) where observations can be recorded in real-time, for further discussion during the retrospective meeting.
- Define Project Success. Define the measures of a successful project before even starting and then evaluate your project, using data, against those criteria.
- Retrospective of Retrospectives. Periodically conduct a retrospective on the retrospective process itself. Continuously improve at improving! Usually, the focus of your project retrospective is the most recently completed project. Periodically, introduce a trending retrospective that seeks to examine the performance trends of your projects over time. I also recommend using these retrospectives to evaluate the value delivered by projects over time.
- Continuously Improving through identified actions
- Maximizing your retrospective's results. Ensure that the output of your project retrospective is shared and your newly acquired wisdom is applied to other projects - 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 project. As I write this, my department's twelve agile teams are completing nearly fifty retrospectives per year; it just doesn't scale well to have each team publish actions and hope that all subsequent 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 project team members & management). Resist taking the easy path with "one-off" improvement actions that are unlikely to have any sustained improvement impact.
- Tracking Completion of Improvement Actions. For Scrum teams, 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 process for selecting from that backlog, completing them, and reviewing the result.
- 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." Two additional factors should also be considered: 1) Impact: how important is this action? If it is fully addressed, will it significantly improve our project 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.
The 8 hours it would take to read the two books, watch the video presentations, and study all of the articles/slides referenced in this article is certainly a sound investment of time if you are looking to maximize the impact retrospectives can have on your projects. Continuous improvement is no longer the sole responsible of process engineers and line management; it is now an element of responsibility for every member of a project team. Consider immersing yourself in these reference materials as you prepare to use retrospectives as part of your project activities.
The next article in this series (Article:Retrospectives 4 - The Perfect Project Retrospective) presents an outline of the activities before, during and after the retrospective meeting, along with several specific tips on conducting a project retrospective.