Continuous Review

Continuous Review is used throughout the development process: after any major event, incident, delivery, mission failure or success. Continuous Review encourages “blameless reporting” and removes any threatening posture or assigning blame for errors, omissions, and mistakes. The point of Continuous Review is to focus on the ultimate goals of the team: what can we do better next time, what weaknesses do we need to address, what successes can we leverage.

Pain Points

• The team is so busy working, they don’t take time to look for a better way to work. See ThreeTrackAttack
• Managers look for a team member to blame when something bad happens
• Different team members make the same mistakes
• Changes to prevent an error don’t get implemented, and the error happens again. And again

Benefits

• Identify problems while they’re still small and easy to resolve
• Provides the opportunity to take SmallBitesAlways, preventing huge disruptive changes
• Provide ongoing platform for individual and team learning

Assessment

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

First steps to create this habit:

What Does it Look like?

Reviews go by many names: postmortems, retrospectives, After Action Reviews, or “acting on the system.” You do reviews to improve the work system, the work, and as part of your learning. Don’t use emotion-laden, threatening terms such as “errors,” “investigation,” or “failure.” Use more neutral terms such as “incidents” and “analysis.”

The TeamSync provides a daily opportunity to learn from events such as code reviews, crashed systems, or redesigns due to missing or misunderstood information. Small learnings and adjustments can result in huge benefits when delivering user capabilities.

Other reviews happen periodically. For teams using a TimeBox, the end of the TimeBox is a convenient time to hold a review. Teams that have moved to continuous delivery will use third track of the ThreeTrackAttack, Refine, for periodic reviews.

After Action Reviews are well defined to encourage on-going learning:

“Key is the spirit in which AARs are given. The environment and climate surrounding an AAR must be one in which the soldiers and leaders openly and honestly discuss what actually transpired in sufficient detail and clarity that not only will everyone understand what did and did not occur and why, but most importantly will have a strong desire to seek the opportunity to practice the task again.” —TC 25-20 “A Leader’s Guide to After Action Reviews”

Include everyone in a review who needs to be part of the review. Each person on a team has a unique view and memory of what happened. Their observations are essential to understanding what happened.

One way to help CreatePsychologicalSafety is to start each review with Norm Kerth’s “Prime Directive”:

Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand. —TC 25-20 “A Leader’s Guide to After-Action Reviews” 1993

The OODA loop can be used for reviews. See SmallBitesAlways for a discussion about the OODA loop.

• Observe - gather both quantitative and qualitative data regarding the event or time period being reviewed
• Orient - find insights for what generated the data
• Decide - on what to do. If an incident happened (like overwriting the repo with a faulty push) how can this be prevented? If something beneficial happened can we make sure it always happens? Possibly use it in another team / department?
• Act - Make a change by performing the action from the Decide step. Then compare the results of the action and the anticipated outcome. Repeat the loop including the new information.

Warning Signs

• Reviews turn into a “witch hunt” looking for the single wringable neck to blame
• Any sense of individual blame, this is a system, after all
• Reviews do not produce any lessons learned
• Lessons learned do not create changes in the system or behavior
• Feedback from reviews is consistently ignore (e.g., “we know this isn’t working but we keep doing it”)

Growth Path

Reviews often exclude managers as they “may bias the team discussion.” This removes a source of knowledge and power to do things from the review. Rather than exclude managers, find a way to include them in a joint problem-solving session.

Keep a record of reviews and proposed actions. Periodically review the record. What patterns do you notice? What items stand out because they don’t fit the patterns? Do you notice alternating events/actions?

How to Fail Spectacularly

• One team’s improvement activity requires another team to change how they work
• Teams add new actions after every review, without checking to see if the previous action was worked on or completed
• Stopping Continuous Review since “the team is too busy to do anything except code”

  ←Prev (Set Team-wide Interruption Protocols)(Checklist for the Team (Stage 1)) Next→

---

Find Out More...

Follow @growsmethod in the Fediverse, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.