The politics of bug fixing
PM Clinic: Week 29 discussion summary
My team has finished major development work and is now turning the corner into bug fix mode. I'm the group manager, and I sat down with my dev managers and dev leads to discuss how we wanted the team to prioritize work. We quickly fell into quicksand. I felt we should be prioritizing around importance - the kinds of bugs that we needed to make sure we fixed.
Most of the development managers/leads made arguments in favor of complexity - they wanted us to focus on how difficult bugs would be to fix. The case in point were two examples:
My argument was that A should come before B, since Pri 1 features come before Pri 2. But they're argument was that B should come before A. Since they bet we'd have to do it anyway (Executives wouldn't let it ship), and since it was a big work item we should take it on first.
I quickly realized that my team wasn't prioritizing for itself - but was prioritizing bugs around management and other perceptions of how other people in the organization would *force* us to prioritize bugs. So in essence my development team wanted to make pre-emptive political choices when it came to bug fixing. Any advice for making this process less frustrating?
- Lost in defect politics
Common bug fixing criteria
Just for reference, here's some common criteria for evaluating bugs. Priority and Severity are two related but different criteria that all bugs should have.
Severity of this item.
Priority of this item.
Common project timelines that impact bug/defect decisions
Many projects use milestone to indicate overall progress. This basic timeline can be mapped to most methodologies. If defined right these help frame how bugs should be managed at any given time.
Managing general bug politics
Early on in the project someone has to define the criteria for evaluating bugs. Even if it's just the list above (Priority and Severity) it will reduce the number of arguments people have, and elevate the quality of those remaining arguments.
The project goals should serve as the source for decision making. The goals should be interpreted against the current situation (bug count, remaining schedule, etc.) by team leaders and specific instructions should be presented to the eam. If the project goals need to be changed to reflect the current situation, then team leaders need to be very public about this.
So if you find yourself constantly fighting the same battles over bugs, talk to your manager or other team leads. Ask them for advice on how to avoid repeating the same arguments over and over again. if you are a team leader, it's your job to step up and provide the team with some guidance.
Common ways bugs are manipulated
Here's a partial list of things to watch out for:
Managing bug manipulators
If you're dealing with people that are playing games with bugs like in this week's situation, here's some approaches:
The real costs of bug fixing
Several folks commented that bug fixes are often evaluated heavily on their programmers work estimates. This is shotgun thinking: typically the testing time is the bigger hit, especially late in a project. Another important criteria is the probability of fix related faults (bugs caused by the fix to the previous bug).
It's important for team leaders to hold fast to their goals: if the priorities are really the priorities, then the amount of time it takes to fix a bug isn't the most important criteria (unless two bugs are of otherwise equal value to the project).
Mark Colburn, Shep McKee, Karen Barrett, Steven Levy, Faisal Jawdat, David Gorbet, Andrew Stellman, Scott Berkun (editor)
The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.
PM Clinic discussion group
|All content copyright 2005. Scott Berkun.||RSS Feed|