One of the Agile practices is that all bugs should be fixed within the iteration that they are produced. The reasons are probably obvious – you don’t want to accumulate a lot of product and schedule risk by building an unwieldy pile of issues. Worse yet, when you do decide to ship you find your ability to do so severely limited. You frantically work to stabilize the product but find that your attempts to fix bugs are sometimes creating new ones. It’s a frustrating time for everyone involved. Better to avoid this and simply keep things clean as you go.
So, now that the scales have fallen from your eyes and you see the error of your ways, how do you make it right?
Most developers understand that the unstated social contract is that “you fix your own bugs”. For that reason, few will argue is a bug recently introduced by them is assigned to them to be fixed. Larger system issues that seem to span features or subsystems can be a little harder, but usually you can get it down to one or two people that will feel some accountability for the problem. Start by declaring that from this day forward, new bugs will be fixed as they are introduced, and enforce it by making it clear that features are not done until all of the bugs related to that new feature are complete. The teams might grumble, but the testers will thank you and the developers will fall in line.
BUT…be prepared for what happens when you realize that you also need to tackle the bug backlog. Come on, admit it – you have one. It might even have hundreds of low to medium bugs in it, the detritus of countless triage sessions in which you realized that fixing this bug was not worth the energy or risk, so the collective decision was to push them to the “next release”. When the next release comes, you realize that the priority of the issue was low then and nothing has changed, so in all likelihood it is even less important now that they get fixed. This is the slippery slide which sustains mediocre products in the marketplace.
However, now that you are living the Agile lifestyle, you have decided this is not good enough. You are going to dig yourself out of that hole. First, be practical. You can’t fool or force your team into investing its energy in a pile of relatively worthless problems. If you have issues that are over a year old and that have been pushed out for 3 or 4 releases, you may want to admit that you really don’t intend to fix it. The best way to get started on this problem is to do a frank housekeeping sweep and clean out all the stale issues.
Waterfall - Mankato, MN
Now that you have a smaller set of more actionable items, what do you do? If you are already working against story points and measuring team velocities, then one helpful technique is to actually assign these defects story points. We tried this out and found that as long as a team is getting new “credit” for the fact that they are fixing old bugs introduced by someone long gone, the work becomes tolerable. With each buying session for each iteration, you can now set aside a portion of the team’s capacity (say 10-20% of their estimated story points) to buy defects. Don’t expect your product owner to be happy about this arrangement – they were likely part of the triage that created the pile in the first place. Instead, the commitment to make this happen needs to come from the Director of VP level in the technical team.
Product owners are forced to balance a number of opposing forces – market demands, competitive moves, sales tactics to close near term business, etc – with all of these things to consider, the thing most likely to get short shrift is product quality. You can’t even trust your customer to make that decision – I learned this valuable lesson years ago.
At the time, we had a relatively new machine in the market and a customer that was evaluating that machine with the intention of buying 40 more had run into an issue during the evaluation. Our team was working into the evening to fix the problem and we were fortunate enough to find a solution. The developer that was working on it had tested it, and it was my call to decide what to do. I decided to contact the customer, let them know we thought we had a fix but that it would be another day before we would complete our testing. I knew they were under some pressure to get the evaluation done right away, so I decided to offer them the chance to “beta test” our fix while our testing continued. They of course said yes, so we bundled up the fix and sent it to them.
The next morning I got an irate call from the customer. ”Why did we send them a fix that only introduced new problems?” they asked. I replied, “But I thought you understood that we had not finished our testing and that there might be problems with it.”
That’s when it hit me – no matter what I did to set the expectations of my customer, THEY DON”T ACTUALLY EXPECT THERE TO BE ANY ISSUES. Nothing you say in advance will diminish the effect on your reputation when those problems are found. If you listen to what they tell you, you will ship a product before it is ready. If you really pay attention not to what they say but how they act, you will realize that you should not skip important steps for the sake of expediency.
The moral of the story? You are responsible for your own reputation, and only you can make the right decision when it matters most. Don’t put your reputation for quality in the hands of your customer, your product owner, or your VP. It’s your decision.
This is the consumate challenge. No matter the setting of expectations the VP, customer, sales rep all simply want no problems. In systems so complex it’s hard to imagine where the expectation comes from but it is a forgone conclusion in the minds of many. The point about maintaining your reputation is well said but the collateral damage that could affect a career are very real too.
Comment by J. — October 25, 2009 @ 6:51 am |