AMIA#02 | How to Get Out of 'Whirlpool of Defects' in One Hour Today
Aha! Moments in Agility
Live in your inbox every Sunday to help you build valuable software sooner
AMIA: #02
Reading Time: 5 minutes
Hey… I’m Adnan. welcome to the new 10 new subscribers this week. And… 220 new connections on LinkedIn. Thanks for sharing our thoughts to the wider network.
In today’s email:
The story: How to get out of whirlpool of defects as a team.
Book club: The 4 stages of psychological safety
Agility Tip: Psychological safety survey
What are the consequences of defects for flow?
Let’s begin with answering this question.
Work flows on the board… from left to right.
On the left, a Dev picks a work item, does the magic and does something to trigger the testing step of the flow.
The QA may be busy testing another work item…
So, there is a queue i.e. waiting time.
Note this… any time there is a hand over of the work… there will be a waiting time.
Now the QA has finished testing previous work. Ready to pick up the new work item.
But, they’ve found a defect.
There is some back and forth between the QA and Dev and they decide it warrants created a Defect item.
But… the Dev is working on another thing he’s already picked up.
One way or the other it means, you guessed it, waiting time.
Keep the story going… I’m going to let you play with that.
Queues and handovers mean the work is not flowing.
So.. assume that a Dev takes 2 days to get work to the QA. The QA takes 1 day to test.
But… everyone has been assigned work; we are busy.
Let’s say the work stays in queue for 3 days between the Dev and the QA.
That means Cycle Time = 2 (Dev) + 3 (Queue) + 1 (QA) = 6 days.
Side note: if we are able to increase dev efficiency so the work gets done in 1 day…
It will not make a big difference. The work will get done in 5 days.
Add a Defect in the Pool
Six days is the Cycle time without a defect.
As we add a defect in the flow, it introduces more handover, queue and work time.
The reason the team is having difficulty meeting the sprint goal is because of this waste. Defects just exacerbate the situation.
It adds stress and extra work. The first casualty is quality. Thus… the beginning of the whirlpool.
How to Identify there is an issue?
You’ll see increasing friction in the team.
The stand up will show a heavy, blocked board. People will have their names against multiple work items.
Most importantly, the flow will be blocked. QAs will not mark work closed as they are waiting for the defects to be fixed for re-testing. Meanwhile, they keep creating new defects.
If this is a familiar scenario, you’re in the whirlpool.
It’s time for Root Cause Analysis.
Here’s How to Inspect and Resolve this Issue
Root Cause Analysis is simple... just follow these steps.
Step 1 - Classify Defects
1. Collect defects from recently completed iteration.
2. Gather your team... (hint) you can do this in a retrospective.
3. Review the classification categories for common understanding.
4. For each defect, read out the details and choose a classification.
5. Enter the sum of each classification in the Total Defects field
Tips
1. Don't spend too much time on classification. If there is a confusion, skip to the next defect and come back later.
2. You are only identifying defects by classification.
Try not to go down the rabbit hole...
Step 2 - Take Corrective & Preventative Actions
Now is the time put the thinking hat on...
Pick one classification For e.g. 'Requirement' and analyse the defects...
1. If the defect still exists, brainstorm corrective actions.
2. Next... and this important for continuous improvement, brainstorm what preventative actions can be taken to avoid this defect in the future.
3. Copy this sheet for each type of defect classification you want to work through.
Tips
1. You don't have to work through all classifications at the same time. Break it up, do the most valuable work first.
2. Corrective and Preventative actions will require team's capacity. Make sure to add them to planning for priority.
You are now on the way to improving quality, throughput and a more joyful, stress free experience for the team.
Bonus - Defect RCA Template
I use an excel template for the RCA exercise with my teams.
This template is a step by step work flow for your RCA session.
It will create a chart of the defect causes. It’s a great way to visualize the root causes for discussion with the Product Owner and the wider team.
Book Club: The 4 Stages of Psychological Safety
This week I have been reading about psychological safety. Timothy R. Clark has very clearly defined psychological safety. His outline of how safety starts from stage 1 and has to go across all 4 stages has been insightful.
Agility Tip: Team Psychological Safety Survey
I have made it a practice to survey my teams for psychological safety in the local context every few months.
I have adapted Edmondson’s psychological safety survey.
If you make a mistake on this team, it is often held against you.
Members of this team are able to bring up problems and tough issues.
People on this team sometimes reject others for being different.
It is safe to take a risk on this team.
It is difficult to ask other members of this team for help.
No one on this team would deliberately act in a way that undermines my efforts.
Working with members of this team, my unique skills and talents are values and utilized.
Tips:
Keep the survey anonymous
Use True / False responses
Set the baseline with the first survey.
Repeat every few months.
Make results transparent.
Retro specific areas of concern with the team.
Help me spread the word
Connect with me:
You’re not alone in your agile journey.