GROWS logo

Continuous Review

Continuous Review is used throughout the development process: after any major event, accident, delivery, mission failure or success. Continuous Reviews 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

  • Catch problems while they’re still small and easier to deal with
  • Provides the opportunity to take SmallBitesAlways, so huge disruptive changes aren’t needed
  • Provide ongoing platform for individual and team learning

Assessment

  • Continuous Reviews happen during TeamSync and provide valuable guidance for team progress (100pts)
  • Continuous Reviews are held after a Timebox and provide guidance for team progress (25pts)
  • Continuous Reviews are not held, ever (-100pts)
  • Continuous Reviews are held but are merely rubber stamps with no reflection or improvement (-500pts)

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

Steps to first adopt this practice:

Setup

  1. Use the TeamSync as an opportunity to look for opportunities to review progress and issues.
  2. If the team uses a Timebox, plan a review meeting as the final activity in the Timebox.

Trial

  1. What actually happened?
  2. Why did it happen?
  3. What do we want to have happen next time?
  4. Which activities do we sustain, drop, and which do we improve to achieve that outcome?

Evaluate Feedback

  1. Does behavior and action change after a review?
  2. If not, what holds the existing pattern of behavior and actions in place? How do we change that?
  3. If so, is this something that can/should be shared with others?

What Does it Look like?

Reviews go by many names: post-mortems, 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. Get rid of emotionally-ladened, threatening terms such as “errors,” “investigation,” or “failure.” Use more neutral terms such as “accidents” and “analysis.”

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”

TeamSyncs provide 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 Timeboxes, 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.

Include everyone in a review who needs to be part of the review. 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

A handy process for reviews can be found in 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 accident 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. If necessary, repeat the loop including the new information.

Warning Signs

  • Rigged Witch hunt
  • Personal blame
  • No lessons learned

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

Anti-patterns from the Hall of Shame

  • One team’s improvement activity is a call for another team to change how they should 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→

Follow @growsmethod on Twitter, 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.