Getting critical defects fixed before a software product is released. Right ? Would make a lot of sense, that the release would be considered problematic if there are fairly severe defects open when the product is about to be released. So I was so surprised when I was speaking to the engineering manager of a team which works on the regular subscription product updates release program for a software company (consider the case where a customer has bought a subscription, and every few weeks, the software automatically updates itself with a new incremental version of the product).
In such a case, the showstopper definition has changed. Now, the showstopper is not a severe defect, but anything that imperils the periodic release of the update; since customers have come to expect that there will be a release and may have their teams somewhat geared to handle and implement this release. In such a scenario, even though it seemed so odd that me the colleague was ready to accept a defect in the released product, that earlier might have caused the product release date to be impacted because of the need to accept the defect, analyse the defect and finally incorporate the defect fix. It took some amount of discussion with the colleague before I was able to accept the way their product release was setup to get impacted by defects.
The concept was that the regular updates have a rolling list of defects along with the update, and the customers have accepted this as a standard procedure, to the extent that they study the defect list and identify the ones that could impact them and pass these back to the product team along with a list of priority. This is the case with the multiple large teams that are customers. However, this is not to say that showstopper defects will not be fixed before the product is released. If there are defects that do not allow specific workflows to happen, or cause data loss or something similar that is of a severe impact, these defects will still need to be fixed before the product update needs to be released. However, earlier definitions of what is a severe showstopper would have been released.
A defect that would have earlier caused a product release to be delayed is now considered and evaluated as to whether it really something that is critical enough that it needs to be fixed now and cannot be sent out as a part of the defect list sent out by the product team. This relaxation, just as long as customers continue to trust the product team and its criteria, ensure that the team is able to increase its chances of releasing updates on schedule which in turn actually benefits the team as well as the customers since it increased predictability.
In such a case, the showstopper definition has changed. Now, the showstopper is not a severe defect, but anything that imperils the periodic release of the update; since customers have come to expect that there will be a release and may have their teams somewhat geared to handle and implement this release. In such a scenario, even though it seemed so odd that me the colleague was ready to accept a defect in the released product, that earlier might have caused the product release date to be impacted because of the need to accept the defect, analyse the defect and finally incorporate the defect fix. It took some amount of discussion with the colleague before I was able to accept the way their product release was setup to get impacted by defects.
The concept was that the regular updates have a rolling list of defects along with the update, and the customers have accepted this as a standard procedure, to the extent that they study the defect list and identify the ones that could impact them and pass these back to the product team along with a list of priority. This is the case with the multiple large teams that are customers. However, this is not to say that showstopper defects will not be fixed before the product is released. If there are defects that do not allow specific workflows to happen, or cause data loss or something similar that is of a severe impact, these defects will still need to be fixed before the product update needs to be released. However, earlier definitions of what is a severe showstopper would have been released.
A defect that would have earlier caused a product release to be delayed is now considered and evaluated as to whether it really something that is critical enough that it needs to be fixed now and cannot be sent out as a part of the defect list sent out by the product team. This relaxation, just as long as customers continue to trust the product team and its criteria, ensure that the team is able to increase its chances of releasing updates on schedule which in turn actually benefits the team as well as the customers since it increased predictability.
No comments:
Post a Comment