How to handle defects in Kanban

The Waterfall approach is:

1. Chuck a load of software into test
2. Testers log a load of defects in a tool
3. Developers get around to the defects at some point and work through lists of defects P1, P2, P3 as prioritised by the project manager.
4. Goto step 1 for the next few months (sometimes years)

The Scrum approach is:

1. Smaller batches of software are pushed into test
2. Testers create defect cards (normally red in colour) and stick them in the dev column on the scrum board / card wall
3. Developers tackle the red cards, pushing them back into the test column upon completion.
4. Goto step 1 until all defects are resolved or the sprint ends. Any left over defects / stories are carried over to the next sprint.

The Kanban approach is:

1. Tester pulls a story into Test
2. Tester finds defects.
3. Developer immediately stops what they’re doing and works with the tester to resolve the issues. No defects are logged. No red cards are created. Automated tests are updated.
4. All focus is on getting the story into an acceptable state.
5. Ship story to live/production.

The approach outlined above is strictly for in-development defect management. But, what about defects that don’t get detected and make it into a live environment? These defects are commonly known as Escaped Defects.

In Kanban, these Escaped Defects are added to the backlog and prioritised along with the rest of the product backlog. It might be the case that it get’s expedited but that’s a choice for the Product Owner and other stakeholders to make.