Bug scrub is a word that strikes fear and hatred into the hearts of many Product Managers (Developers, QA leads, Release Managers, and Project Managers, too). Not because of the purpose of bug scrub–dispositioning recently filed product defects–but because the process behind the purpose can end up being so heinous and painful.
For the uninitiated, the Cranky Product Manager provides a valuable, albeit hyperbolic glimpse inside the bug scrub process. She highlights the frequent discord and conflicting interests that makes bug scrub such an ordeal and one that all-to-frequently ends up being internally-focused rather than customer- or market-focused.
Bug scrub doesn’t usually start off as such a mess. Like most things in life, bug scrub starts with good intentions. The goal is to make sure that there are not long periods where bugs are sitting unassigned or waiting for additional details in order to be acted upon. In my experience, bug scrubs get initiated when there is a big release coming and Engineering’s feet are being held to the fire on release management issues, but there are other reasons, too.
There is then a push to have a meeting with all of the “key stakeholders” (read: Product Management, Program Management, ENGR, QA, Support, Account Management, even UI designers) so that consensus can be reached about any outstanding issues. At the beginning of the release cycle, bug scrub typically happens once a week or even every other week. The bug dispositioning is contained within the MRD, so there is no need to create parallel processes. However, during the heavy development part of the release cycle (and all the way to the final GA date), these meetings happen more frequently…once or even twice a day.
There are a few main problems with the bug scrub process:
-
Getting all of the “key stakeholders” to participate
-
Bug scrub is not a democracy
-
Ownership of the bug scrub process
With the first problem, you should count on NEVER getting all of the “key stakeholders” in the same room at the same time. The state of modern-day meeting madness makes it more likely that you will either win your state lottery and/or be struck by lightening. All of the real decision makers in most organizations will be in meetings almost perpetually (presumably making decisions).
Determine who the real stakeholders are and focus on them (this is a political game, so do your due diligence and be careful). Get as many as you can into your meeting, even if it is only by conference call. Don’t worry that not everyone you invited is there, since the more attendees that show up, the more bureaucracy and noise you will have to fight through.
For those real stakeholders that cannot be there, make sure to follow up with them after to fill them in and solicit their input. That will go a long way toward reinforcing the value of their participation and may encourage them to select your bug scrub meeting over other meetings in the future (or not, your mileage may vary).
Problem number two isn’t really a problem for the Product Manager, but it can be a problem for others on the bug scrub team, which usually ends up being a problem for the Product Manager. While the bug scrub process is one that involves input from a variety of groups within your company, the ultimate decision rests with the Product Manager. If that is not the case, then you have a larger issue than a broken bug scrub process.
The purpose of the bug scrub meeting is to gather input. As the Product Manager, you can accept or reject that input. In my own experience, I frequently lean on members of Support, QA and Development to help me understand the implications of the bugs, but ultimately, I have decide whether a bug gets patched, put into the current release (possibly wrecking the schedule), put into a future release or filed away into the purgatory known as “future release.” My decision is based on the feedback that I get from others and the priorities that I receive from the senior management, but it’s my decision.
The challenge is not making the other members of the bug scrub team feel like their input isn’t valuable. It is important, but it’s not the only thing that I as the Product Manager need to consider when evaluating each bug individually and in the context of a release.
Finally, the ownership of the bug scrub process and even who drives the meeting can be a contentious issue. In some organizations, the bug scrub starts off being the initiative of someone outside of the Product Management team. This is bad. It means that someone else is filling in a gap where the Product Manager or Product Management team is not performing.
It can be tempting to let someone else drive bug scrub because it feels like such a tactical process and as long as the Product Manager is involved in the discussion, then everything is fine, but it’s not. The Product Manager MUST own both the process and drive the meeting.
This gets back to the whole perception of filling the void. Both the scheduling and execution of the bug scrub meetings needs to be handled by the Product Manager so that others inside and outside of the process see Product Management taking the lead on priorities. Otherwise, you will notice that more and more product responsibilities will be adopted by others, which doesn’t bode well for your success as a Product Manager.
So, here’s what you need to do in order to “Love” bug scrub–
-
Figure out who really needs to participate and get them to commit to attending your meetings
-
Solicit feedback from team members, but make decisions that are in the best interests of the product
-
Own the bug scrub meetings and process
-
Remember who is ultimately responsible for the product and then act accordingly
Don’t be a bug scrub “hater.” Embrace it. Bug scrub can help you take your product to the next level, but it can also be a huge time/productivity vortex. Manage it well and it will be the former rather than the latter.