How I stopped logging bugs and started living happy

Because there is not such a thing as a best practiceBug-flyer-with-letters_2col

ATTENTION: This won’t work for everybody, all I claim is “it works in my context” and you might try to use it at your own risk.
WARNING: If you believe in best practices that should be applied to every context go away now, you might be harmed by this post

One day, a few years ago, I had a conversation with an inspirational man, he was at that time my CTO. He was talking about zero tolerance to bugs and how beneficial is to remove the annoyances of bug management from the development of software. I was listening but at that time I didn’t grasp completely the concept, because by then, I had never seen neither envisioned a situation where a development team could produce zero or for that matter even close to zero bugs. Since then a few years have passed and I have worked hard on his vision. Today I can say, yes he was right and a development team can deliver value with 0 bugs, I even learned that the project team doesn’t have to spend half of its time playing with a bug management tool to file, prioritise and shift waste.

Let me give you some context around my project and current practices:

Two co-located cross functional agile teams each with 4 developers, one tester, one business analyst, one product owner one dev-ops guy and a team lead also known as kanban facilitator (18 people)

Kanban Board
Kanban board visualizing our process. (Discuss, Distill, Develop and Demo are stolen from the great work of Elizabeth Hendrickson)

1. We use Kanban to visualize our process and we have the ability to deliver every time we complete a user story if we wanted.

2. User stories are small and we create them so that we can deliver them in less that 3 days

3. User stories are vertical, i.e. no big bang integration is required between the teams, each team works on the full codebase that spans across multiple applications

4. We follow an hybrid between ATDD and Specification By Example that I have specifically developed for our context

5. Developers code review every line of code before every push, we also do some pair programming mainly to train junior developers

6. Developers maintain a healthy 95% or more unit test code coverage, we also enforce all of Sonar coding rules

7. Some of the developers practice TDD

8. We use Jbehave and Thucydides to automate ~100% of our acceptance tests

Our ATDD approach
Our ATDD approach

9. We have an internally developed “platform on demand style” build and deployment pipeline that runs all our functional tests and performance/load tests that check variations against a known baseline

10. Every automated test runs after every push to trunk in such pipeline

11. Every push to trunk gets deployed automatically and can be manually promoted to exploratory testing stage and beyond

12. After all the acceptance tests pass for a user story, we do exploratory testing on it

13. After exploratory testing is complete, we demo to our product owners that subsequently do user acceptance testing before accepting the  story

14. If a bug is found during exploratory testing or user acceptance testing the developer(s) that worked on that user story, drop everything else they might be doing and fix the bug, the card will NOT progress if a valid bug  is not fixed.

15. If a build becomes red, the developer who causes the instability drops everything else and fixes the issue straight away. Build must be always green.

Project Wall
Project Wall

16. When a developer fixes a bug, he writes automated tests that cover such path

You noticed I mentioned bugs in 14 and 16. Yes, of course, we are humans and we make mistakes, this doesn’t mean that we need to celebrate the mistake and make it visible by logging it in bug tracking tools that we will need to run and maintain among with the waste stored into them when the poor bug has the life span of an unlucky butterfly.

When i find a bug while exploratory testing I simply go to the developer and tell him, look pal I think there might be an issue, come to my desk and I’ll show you. If he needs to go home and can’t fix it straight away, no problem, I will stick a red post it on the user story card on the physical Kanban board with 2 words describing the bug so nobody will forget. BTW that card is not going anywhere until the bug is fixed and buried. The red post it goes into the bin after the death of the bug.

The development approach we follow, allows us to have a very good understanding of the business value we deliver as we do group discussions to derive examples for each user story, when you add a bunch of excellent developers that follow good engineering practices you will find out that the bugs you discover when exploring the software are very few, once you act upon them immediately, no excuse, bugs become something that doesn’t really

More Story Wall
More Project Wall

bother you.

In this situation, logging and managing bugs is simply waste and we all live happy with no bug ping pong between developers and testers, no bug prioritization meetings, no bug triage meetings, no bug statistics, no need for bug trends to identify product release dates, and guess what we deliver bugless software that delights our customers.

EDIT: I am not alone! Have a look at the great work from Katrina here http://katrinatester.blogspot.co.uk/2014/11/different-ideas-for-defect-management.html

Advertisements