Does Kanban imply the removal of bug tracking?

Question

The software development planet is in a phase of huge transitions. There are many sdlc models being introduce and transformed like Agile , DevOps , DevSecOps and so on.

One of the main shift I noticed is the shift from scrum to Kanban. The board , the talks , and all the other new stuffs looks fun , but there is a huge red flag ( as a QA ) and that is the "Idea of removing bug tracking " all together

The below article is one of the example:

https://codeburst.io/life-without-bug-tracking-925668ed6842

Recently, I attend a test Meetup for Kaban. In which , even the agile coach was suggesting the removal of bug tracking and introducing 3 amigos.

And a few of the thoughts that came up was

1. How efficient is this process ?
2. How can you manage bug count >50 using 3-amigo. ?
3. How do you keep the QA motivated if there are no way to track thier efforts ?
4. What KPIs to use if the bug count itself is removed?
5. How do you prove that a decision of "not to be fixed" was taken by the PO or Dev?
6. How to prove that its not a defect spillage , but a decision of "not to be fixed "?
7. How do you track the resolution made if a similar issue occurs in future ?
8. How can bug fixes be assigned to developers according to available capacity?
9. How to validate that bug numbers are reducing with each Sprint ?
10. What would be the real role of QA in this case ? How do you retest a bug if you don't have tracking at the first place ?

Question:

What is the best approach to implement Kanban efficiently

Answer 1

I think the article you link confuses two different things- bug tracking system is not the same as the bug handling process.

Saying "If it is non-critical, you drop it." doesn't mean you don't track the things you are leaving, tracking can be done in using any system you like and in this case it's the Kanban board. The opposite is also not true, you can still drop non important bugs even if you are using a tracking system.

How efficient is this process ?

In my Kanban we used to have periodic bug triaging meeting where old or non important bugs were simply closed, while trying to keep a zero bug policy- bugs that required big architectural changes were converted to new feature requests and closed, others were solved asap. We didn't have a dedicated bug tracking system but the relevant Kanban tasks were marked as bugs for clarity.

It was rather efficient for our product that was stable with high pace of development and relaxed stability requirements, I can see it being less efficient for new products where a lot of bugs flow in

How can you manage bug count >50 using 3-amigo. ?

I'm not sure what does it mean in this context, but having periodic sessions to evaluate bugs instead of reacting to them in realtime can limit the disturbance to the development flow.

On the other side if your product have too many bugs you should stop and consider your position- is it because of low quality ? because you are still under development ans stabilization ? in the first case consider stopping and improving quality before you continue development, and in the later you can probably safely ignore the bugs or tack them temporarily.

How do you keep the QA motivated if there are no way to track thier efforts ?

I don't see the problem here, bugs are still discovered and communicated why do you need a special system for that ?

What KPIs to use if the bug count itself is removed?

Bug count should never be used as a KPI in the first place, use the other KPIs you will usually use to assess the things you want to assess (or in other words, you need another question for that)

How do you prove that a decision of "not to be fixed" was taken by the PO or Dev?

Prove ? unless you are in a highly regulated field why would you want to prove anything ? a team is based on trust and team members not abusing the system. Anyway, Kanban doesn't mean that tasks are not being tracked, they are simply called otherwise in a non-dedicated system

How to prove that its not a defect spillage , but a decision of "not to be fixed "?

Same as above

How do you track the resolution made if a similar issue occurs in future ?

See the above, but that's really a disadvantage to using a general purpose system

How can bug fixes be assigned to developers according to available capacity?

That's the strength of Kanban- a bug is just another prioritized task in your list

How to validate that bug numbers are reducing with each Sprint ?

See above, bugs are still being tracked

What would be the real role of QA in this case ? How do you retest a bug if you don't have tracking at the first place ?

Same as before, only now it's a Kanban task and not a bug

Answer 2

The removal of bug tracking doesn't mean the removal of bugs !

In fact the ability to find and spot bugs (your skills) are more important and timely than ever.

It can feel very comforting to log bugs. They prove (validate) that you found stuff. They add to a mountain of work that needs to be done. See that backlog grow! Unfortunately we're moving away from the customer here. Also, you have full control on adding the bug initially - no-one is there to 'argue' against it so it is very empowering personally.

Your organization may need to adjust approach / thinking at many levels and for many roles. This sort of change is very hard. You don't keep track of 50 bugs 'cos you don't allow 50 bugs to accumulate. Either fix it now, or decide it's ok. Just avoid the dreaded backlog. What's to stop finding the buig over and over? better coimmunication. Everyone should know about bugs that won't be fixed and accept it. If you don't have that culture yet, more work is needed in that area.
This does require big changes though. For example you might need to aim for 50% velocity (gasp!) to allow for time to really fix stuff as it comes up. Your ability to estimate and manage this will improve over time.

Don't let your bug tracking system replace the personal communication you should be having

After all https://agilemanifesto.org/

Individuals and interactions over processes and tools

Have I actually see this work? Yes. In my last position I made sure the backlog (including bugs) was constantly reworked and massaged. Over time I was able to keep it at a similar size, in fact over six months it actually got smaller as we became better about this 'fix or forgo' approach. Caution: it took me 5 different jobs to get to this point!