In the previous post in this series (Getting advice from the team about status), I talked about the importance of making sure that feedback from the team is not crushed, and that people are not put in a position where they feel that they are doing something against the organization when they report status that is not comfortable, or where they say that according to them, the product is not in a good position.
Now, for a large product, there will be several layers of organization that will be working on the product, and it is good to remember that all of them have some fact and some information that may be relevant or may not be. In fact, in today’s world where user forums are a quick way for a problem to be reported and then more me-too’s to quickly join in through social networking, it is very hard to determine which issue is a huge problem and which is the one that can be safely ignored. It may seem strange to those outside the industry, but it is very much possible that a defect in the program that may be irritating to that specific user or cause some problems may not be something that the team considered worthy of fixing.
The next few lines will not be about the decision making, just more about what goes on as the team nears the release date. As the product gets closer to release, and the situation is not such that there is absolutely no chance of release (if the team is indeed in such a bad situation, it will be visible to everybody and decision making will be much easier), the status with regard to defects in the application will become much more complicated. It is a known part of the software development process that when the team gets near the release date, selecting which bugs will get fixed and which ones will not be fixed (or will be deferred from the current release) gets tricky. Closer to the release date, the problems associated with enhanced risk for every defect that is fixed become critical. What this means is that unless the defect is evaluated to be sure that this is needed to be fixed, and that the actual fix will not end up destabilizing something else, the team may well decide that the problems sought to be taken away by fixing the bug are not worth the risk, and a larger proportion of bugs will be deferred (and not fixed).
Deciding which of these bugs need to be fixed and which one needs to be deferred is critical. However, this should be an independent decision by the Bug review committee having the Product Management representative, and (to emphasize), it should not be under enormous pressure to defer bugs in order to meet the schedule. What this means is that it can happen easily enough that the management team relays the pressure down to the team that it needs to increase the rate at which bugs are being deferred in order to meet the schedule. This tactic runs the risk of letting through such bugs that can be bad for specific sets of users and bring about a lot of condemnation on user forums and among user groups.
Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –
More about this in the next post (link) ..