A Root Cause Retrospective

My goal with this Retrospective is a format allowing teams to break down a few specific issues into constituent parts, look for themes in root cause analysis, and take actions to prevent the recurrence of those factors.

Some specific choices about the Retrospective, and why I made these choices:

A. This Retrospective serves as an introduction or a reminder of Psychological Safety, a space where it is safe for the team to contribute ideas and feedback free from retribution.

B. Team Ownership – Promoting the idea that all of the work belongs to the entire Scrum Team. Everyone has a role to play in success, and includes (but goes beyond) writing quality code. For instance how the Product Owner wrote a story, or how the Scrum Master facilitated events.

C. System analysis instead of individual responsibility and blame. Pointing out that “Bob” caused the problem distracts from finding the systemic cause that allowed the Team to reduce quality. Therefore we have no column for Name, or anything related to individual effort.

To promote these factors, the choices I made in designing this custom Retrospective format include:

D. Input is Anonymous. Although discussion may “give it away”, creating anonymity for submissions, comments, and reactions can provide a small encouragement to speak openly. 

E. Work on multiple issues. I pre-seeded the Retro with several recent incidents. Tackling one specific incident, even one at a time, could create defensiveness in the person closely related to that one (or first) incident. Use enough seed Incidents to promote focus on factors of causality, not sources.

F. Make it clear that we don’t actually care if the cards in columns 2-6 are tied directly to their incident, they don’t need to “line up”. It’s OK to note that information if the participants feel it’s important, but once we get to a certain stage, we “throw away” the Incident cards anyway. We’re looking for clusters of themes that could apply to any incident, rooted in Team dynamics.

Instructions:

1. Create a Retrospective format on a whiteboard or whatever tool you use. You will need 6 columns to start. You will later remove column 1, and add columns 7 and 8 later. Leave room for them. I created mine using a Custom retro format on TeamRetro.com and their process worked well. Research a starter list of recent incidents the team has encountered and write those in column 1.

2. Create the following topic columns. The image at the top shows my column names, colors, and icons. Incident, Discovery, Symptom, Immediate Cause, Root Cause, Correction. Remember to leave room for 2 more columns. Notice that there is no column for “Who”.

3. If you’re using a virtual tool with anonymous option, I recommend using it. To help preserve the anonymity, instruct people to write in full sentences, so that thoughts can be clear on their own, without clarification. What is obvious in one person’s head will not be clear to others, especially surrounded by other cards. Any member should be able to read a card and expound on it, without the originator having to reveal himself.

4. Set your timer (5-10 mins): Invite the team to add additional Incidents in the first column, but have several seeded when they first see the board.

5. Set your timer (5-10): Invite people to fill in any cards within the appropriate topic columns, with details they can remember about the given incidents. It is not important to line them up, or link them to the related Incident. The factors should help to break each incident into concrete, specific actions and findings. How was it discovered? What was the symptom, who did it affect, what was the effect? What was the obvious cause? What was eventually found to be the root cause of the problem? What was done to correct the issue? All factors might not apply to all incidents.

6. Set your timer (5-10): Delete or remove column 1 with the Incident cards. We don’t care about the specific incidents. Instruct the team to identify the most common clusters or themes of factors. Move cards around to group them. It is possible that the same theme may occur in different column, and you can move cards to group them.

7. Set your timer (5-10): Instruct the team to place votes according to which factors they want to focus on. For the number of votes, I would suggest (Number of cards / 4) + 1 for the number of votes per person. They can spread their votes out one per card, or place multiple votes on cards they consider more important. The Incidents should already be gone, so voting is only on the remaining cards.

8. Set your timer (5-10): Begin discussion by sorting the cards by vote totals. Choosing the top themes you want to discuss. Maybe pick the top N items, and timebox for 5 minutes. Adjust based on team enthusiasm and the amount of time you have. If you have a thorough discussion on the top N, you can always choose another and add time. Remind members that the purpose is to determine common causes of incidents, and to create actions or artifacts that will prevent recurrence in the future.

9. Set your timer (5-10): Add the columns for Preventing Recurrence and Artifacts/Actions. Discuss what would prevent recurrence of the most important clusters the team has identified. Write those preventative solutions in column 7.

10. Set your timer (5-10): Instruct participants to choose a small number (maybe 2-4) of the Prevention cards. Ask them how to convert these into specific Artifacts or Actions to take going forward. An artifact might be “an automated testing tool” or creating a specific checklist for a certain procedure (things to do when promoting code to PROD). An action might be creating a specific “role” for someone to do X during every Sprint Planning ceremony. Discuss assigning these Artifacts and Actions to someone specific so they have ownership. Ad a card for each to next Sprint Backlog so that the work is visible and will get done soon. Focus on artifacts and processes that will be more robust than just the “knowledge” of the root causes. People will forget this Retro, but the Artifacts and Actions should cement the lesson into the improved Scrum process.

Published by theAgileCouch

A place to relax and unwind with some Agile Coaching thoughts.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: