Does Kanban imply the removal of bug tracking?
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:
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
- How efficient is this process ?
- How can you manage bug count >50 using 3-amigo. ?
- How do you keep the QA motivated if there are no way to track thier efforts ?
- What KPIs to use if the bug count itself is removed?
- How do you prove that a decision of "not to be fixed" was taken by the PO or Dev?
- How to prove that its not a defect spillage , but a decision of "not to be fixed "?
- How do you track the resolution made if a similar issue occurs in future ?
- How can bug fixes be assigned to developers according to available capacity?
- How to validate that bug numbers are reducing with each Sprint ?
- 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 ?
What is the best approach to implement Kanban efficiently
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