Breaking the waves

We were in painful position with a lot of reported bugs and lot of unhappiness among, well among everybody. I was reading the book Implementing Lean Software Development (Poppendieck & Poppendieck, 2006) and got a lot of ideas and inspiration to implement a better way of working.

The outcome? The support staff felt safe knowing that they could report an issue and that it would be handled quickly. The developers was not disturbed that often anymore, preventing multitasking. They also got a better understand of the consequences of their actions. The busy product owner found a way to share a little bit of the workload.

Image borrowed from here

This is how we implemented the ideas from the book.

Delete all old bugs
To get a fresh start delete the existing bug list. Don’t worry if you delete one bug  too much. If it is important enough someone will report it again. We created a limit on the bug list. If the number of bugs exceeds 30, something must be removed from the list. If a bug list grows to big it will not be reviewable any more and will probably contain duplicates and such. The lean principle that error hides in piles of inventory also applies here.

It shall only be possible to report bugs at one place
We are using VSTS and created an inbox for bugs reachable for all stakeholders. No more bugs that are lost in emails.

Create a good bug description template
We want to avoid that there are missing information when a developer finally starts working on the bug and the description has to be completed by someone who no longer remembers the details (churn). We therefore want a well written bug report. Our reports contains besides reproduction steps also customer impact so that we clearly understand how the fault affects the user. We also include expected and actual result to avoid any misunderstanding of what should be fixed.

Create  a short feedback loop
We created a daily  meeting called Daily Triage to prevent that a bug is unattended too long. To make it a snappy and effective meeting we time boxed it to 15 minutes. We have visualized the number of bugs in the triage inbox on a screen, so if the inbox is empty everybody will know that the meeting is canceled. If something really critical is happening it is ok to call for an extra triage. We also made an agenda for the meeting to avoid a lot of unrelated chitchat. For each bug in the inbox we ask:

1) Is the bug correctly reported?
If not send it back to the submitter with feedback on how to improve the report.

2) Is it a bug?
Some people tend to use bug reports to introduce more functionality. That sucks. If it is a request for new functionality it should be prioritized against the rest of the backlog and handled the way we handle other customer requests.

3) What is the severity?
Setting a severity helps us discussing the priority and ROI.

4) Should we fix it?
Is the ROI high enough? If yes put it on the buglist. If no, report to the customer / submitter that we will not fix it. Sometimes it has happened the we had said no to fix a bug, but later reconsidered that decision when more people has reported the same thing and the ROI of a fix has increased.

Make the right people attend the meeting
In order to empower the meeting to make decisions we have people from development, support and a product owner attending the meeting.

Making this process a part of a Kanban flow created a really efficient bug handling shop. Triage an item in the morning, fix it and test it during the day and then deliver it around 04:30 next morning. Compared to deliver once a month it was a huge improvement. (Making small deliveries often, is one of the best quality investments you can do. It is a lot easier to build quality in when working in small batches.) The delight of customer getting their issue handled that quickly often exceeded the annoyance of having to report the bug in the first place.

One of the other important things we did was giving one of the teams working on the product the mission to handle customer failure demands quickly. Functioning as a wave breaker so that other teams could spend time doing new development and paying off bigger chunks of the technical debt. So two years later how did it go? Well last time I checked we had three open bugs. Quite manageable!




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: