In a previous post, I was proposing to reduce the number of defect priorities to three. In the project I work on we currently have five. Elements in the last two gather dust (so to speak) because no one is looking at them. We know that things that stand in these priorities will never be fixed.

It made me wonder why we picked five priorities. I suppose it was an attempt at having fine grained prioritisation. In practice however we only use three priorities: must fixed in the next day because something really important and central is broken, must fixed before next release because the users cannot live with it and the fix when you have time/opportunity defects.

That makes three priority levels. And it ensures none of the reported defects falls into oblivion. I am under the impression that this combined with a defect time value and putting defects reported by users in the first two priorities would help manage defects in a sensible manner.

What is your practice ? How many priority levels do you use ? Is it that we have too many defects, period ?

In a previous post, I was proposing to automatically assign a very high priority to a defect reported by a user (user in the released product). Arguably many of these defects are not critical and for the critical ones arguments against this idea will be short lived.

Why assign a high priority to non critical defects reported by a user ? I have at least two good reasons for this.

First, because a user took the time to report such a defect, it had to be very visible and quiet annoying at the time he discovered it. That should be enough to put it ahead of anything that was found in the rest of the software development process that was not scheduled immediately for a fix.

Second, it is a very strong signal from the team to the user that his feedback is valued and acted upon. This in turn will encourage users to report not only cosmetic defects but also inefficiencies in the way their workflow is implemented. It is actually something that I have noticed in many cases, until the cosmetic noise is gone, many users do not focus on the actual workflow and usability.

In many cases, our appreciation of what is important is different from our users’. Putting a high priority on defects that are reported by the user makes sure we do not substitute our priorities to his.

What do you think ? Are defect reports from your users useful ? Is it easy for them to report defects ? Would this introduce too much noise in the defect tracking system ?

Joanna Zweig and César Idrovo have a second article in the agile journal about building common purpose.

Let me only reinforce that organisations that wish to involve everyone in the decision making process at all levels should remember to introduce it progressively. Tocqueville noted in his Democracy in America that when people are not used to make the small decisions (or participate in making), you cannot expect them to be able to participate usefully in the big ones.

A lighter touch, fun video by Jonathan Coulton via Chris at TMI

In a previous post, I was proposing to assign a time value to defects and have them expire automatically after a while. As a disclaimer, obviously it would be useful to extend the life of a defect if desired. The rationale behind this falls on two points.

First if a defect stayed untouched for a long time (and assuming it still exists at that time) it is likely to be benign and somewhat irrelevant to the end users of the system. They would otherwise have raised the visibility of this issue (assuming that communication channels are available for them to do so, but that is a different problem).

Second if the code base is being modified actively, it is likely that some of the analysis, the steps to reproduce the defect and how it manifests itself have changed. It could also happen that the defect has become completely invalid, either because it was fixed, belonged to an area that has been removed or thoroughly re-factored or that the focus of the product has changed (remember we are in an Agile environment).

We should let our defect tracking system be our memory. Let our defect tracking be forgetful of unnecessary details to make sure it provides us access to the important things.

What do you think ? Do you often go through older bug reports ? What are you using them for ?

Funny how things take a new light when you measure them. Take bugs for instance. When I started on measuring the time our current, reported, bugs have been opened I was expecting something like this:

For full disclosure, we use five level of priorities and we have a policy to fix all outstanding P1 and P2 bugs before shipping a release. What I found was this:

So effectively, we are not fixing anything that is below P2 in a reasonable amount of time. P5 are unlikely to be fixed anytime. Still we spend time managing that inventory of bugs (trying to avoid duplicate bugs, reviewing the priorities from time to time). In pure waste.

A second thing came to my mind looking at the mean time bugs stayed open. Given the amount of changes the code base undergoes in 6 months, what is the validity of a bug that was recorded at that time and was not considered important enough to be fixed ?

I will throw in a few ideas here that could lead to improvement in this area. One thing I would love is to be able to time expire defects.
Anything older than a coupe of releases should disappear automatically. Assign a high priority to defects reported from the production as they are truly visible and of value to the users who reported them. Reduce the number of priorities to three. Do not bother to record things that are evaluated below P3 in our current scale. Stop the line for anything
that we know we want to fix at the time of discovery. Each of these ideas will require a dedicated post (coming soon).

What are your thoughts on defect management ? Are these ideas outlandish ? How do you manage defects efficiently in your projects ?

It used to be that I did not care much for defensive programming outside of a system’s boundaries. It used to be that I did not really care or believed in strict source control (as in authorise only some people to touch a particular file). It used to be that I did not really believe in code reviews.

I now care for these and it is not a good thing. I care about these things because I do not trust the developers I work with to do the right thing, whether it is making the code better, improving their style, teaching me new things, or even write descent unit tests.

No that I am perfect in any ways but I used to be able to trust people in the team to correct me and help me get better. I used to be able to trust people on the team to catch my mistakes and fix them.

Work is a lot less enjoyable when that trust is gone.

In the recent past I noticed an interesting property of self adjusting systems. They self adjust !

So when work in progress started to accumulate and stories ‘completed’ piled on the doorsteps of QA, production of new features essentially stopped. Granted, part of it was due to the number of bugs found. But given the level of energy displayed by the team, that was not the whole reason. Here is how physical systems work: when a pipe is blocked water stops flowing and typically an equilibrium is reached where water becomes stagnant at a stable level. When no equilibrium is reached it is called a flood.

Since then our team’s management has had a good idea, tell people what they were expected to finish by the end of the year. Not surprisingly, setting a clear goal energised people a bit and production has started again. Work in progress has tripled and the pile in on QA’s doorstep has doubled. Nothing short of normal in a two iteration period.

On the positive side we have the opportunity to get the development team rolling into the new year with the warm feeling of mission accomplished. Sure we now all know what mission accomplished means. It means there is a whole more work to be done before the work is actually done and delivered. But having a sense of accomplishment, given the tough economy and looming work force reduction, will be invaluable.

On the negative, let’s brace for a good month of flooding.

Joanna Zweig and César Idrovo have embarked on a journey to discover the coveted team jello, the thing that makes team jell. Best of luck to them.

Can’t wait to get a taste of it really !

I have just finished this book
this book by David J. Anderson and it was truly a breakthrough for me. It enabled me to go beyond the religious feeling of Agile to management science and why Agile methods work. Sometimes. It also lead me to finally understand what my company’s business is !

My book list just got longer by adding Domain Neutral Component, Theory of Constraint and Feature Driven Development to it.

And I encourage everyone to read the excellent CMMI-Agile article as well as another one on negotiations (both through David J. Anderson’s blog).