If you are in a buggy group, you have a lot of bugs.
After writing the preceding, I’ll endeavor to make the rest of this post slightly less obvious.
Anyway, so, you have a lot of bugs, and you need to get better. How can you get started?
Well, there’s a common technique in agile called root-cause analysis. It’s a good technique, but your team isn’t ready for it and you can’t afford to do it.
Instead, I recommend a technique I came up (probably not uniquely) that I call “bug categorization”. I started this when I team that I was on had a notably buggy iteration, and I noticed that a fair number of the bugs were just sloppy – not reading the spec, not running the app after they had made a change, that sort of thing.
What I wanted was a way to help the team to clean up their act without being prescriptive.
So, I went through all the bugs – something like 120 – and did a really quick classification on each of them, putting them into one of the following categories:
- Foreseeable: This is a bug that we should have caught.
- External: Somebody else broke us.
- Existing: This bug existed in past versions of our software.
- Spec: There was a problem with the spec.
- Other: Something else.
At our retrospective, I presented a graph of the bugs, and then put up a post-it that said, “too many bugs”.
And then I let the team work on the problem. And they did great, cutting the foreseeable bugs significantly in just a few iterations despite me expanding the definition of foreseeable to include more bugs.
And while my initial impetus was to reduce the sloppy bugs, the team spent a lot of time fixing bugs related to definition and communication. For example, they invented a dev/test/pm meeting that the start of a story to make sure everybody was on the same page.
So, that’s bug categorization.