5

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

Improve this question
2
  • 1
    Not sure why the downvote, but I'm afraid people you talked to don't really understand Kanban. Nothing about Kanban should take away from QA. In fact, the first principle of Kanban is "Start with what you do now". So, the first day of kanban, you will visualize and start measuring flow of work, but you should be changing nothing about your process.
    – Daniel
    Nov 22, 2019 at 2:00
  • @Daniel hi I have added a link to article . when I attended the meetup I thought it is just an individual opinion of the agile coach , but when I saw that the internet is filled with such opinion I was curious to ask this question
    – PDHide ♦
    Nov 22, 2019 at 6:57

2 Answers 2

Reset to default
3

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

Improve this answer
14
  • I like the part of converting bugs to pbis or tasks . It's still a way of tracking it or addressing it . And also I agree to the fact that kaban could be efficient for a stable product and not for a product in development. But about using bugs as KPIs is a way to keep the QA motivated . It is the same like using bug bounties to keep hackers interested in finding more security bugs
    – PDHide ♦
    Nov 22, 2019 at 12:13
  • 1
    That's a different discussion, but simply counting bugs is meaningless without more data (severity, in or pre production, how many bugs escaped etc.) and can lead to abuse of the system. Anyway, moving to Kanban doesn't affect the day to day life- the testing guys will still test and their finding will be logged somewhere
    – Rsf
    Nov 22, 2019 at 12:16
  • 2
    we used to pay for lines of code. we know how that ended
    – Michael Durrant
    Nov 22, 2019 at 12:17
  • 1
    Ofcourse, bug count is not a independent metric. It is coupled with feature stability, complexity, severity, effort required to find the bugs, and so on. Same like getting paid more for severe and highly complex security bugs and paid less for simple ones
    – PDHide ♦
    Nov 22, 2019 at 12:19
  • 1
    NASA Space Shuttle incidennts are also a good example of insanely well tested systems (QA actually outnumbers dev!) that can still lead to massive problems. Like explosions in this case
    – Michael Durrant
    Nov 22, 2019 at 12:20
0

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!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.