Decisions around the product release – part 3 Martin Jansson
What is essence of the discussion on release team/showstopper meetings?
I am assuming that there is a meeting. I’ve been to many different kinds of showstopper meetings and most companies handle them differently. One important item on the agenda for the meeting is usually the bugs that are found late in the project, thus at the end phase where they might be considered showstoppers.
When these bugs are discussed if they are to be fixed or not, I’ve seen cases when the argument is a bit vague. The actual topic is sometimes not brought to the surface, instead it is someone who “feels” that this should be fixed or it should not. What is it that they feel? Articulate those feelings and try to be clear on what it is you see. Why should it be fixed or why shouldn’t it?
In these cases I think it is best to be clear that we talk about cost, at least in most cases, in one sense or another, thus the cost of not fixing it or the cost of fixing it. Some costs will affect support, others will affect marketing and sales and some will affect development itself. I can recommend trying to get everyone attending the meeting to focus their thoughts on what the bugs will cost you. Is a few days slip perhaps worth it? In some cases the date for the release is extremely important, this is most often the case for bigger organisations. Instead it is easier to make some changes after the release decision and make a few patches afterwards. The actual release will not reach the customer the same day anyhow. Either way it is cost you discuss and you most often decide based upon it.
Cem Kaner has written an article on this that I’ve used many times when setting up these meetings. You can find the article here.
Regarding show-stopper meetings.
In many organizations today you enter the show-stopper phase with the philosophy of only allowing very controlled bug fixes; and this phase is very similar on all companies and is also the same regardless of which software development method they have used. I think that this is a legacy from the old big bang processes where everything was tested and checked out in the last phase only. Hence you would strive for having a controlled environment in the end of the project.
But this procedure does not take the latest 10-15 years of development into account.
* When working iteratively, you know more about the application in the end; and you thereby know about the weak spots, the risky spots, etc of the application.
* The unit tests that often accompanies code today is often a good regression test suite where you can get fast feedback on your bug fixes even before having checked in the code.
* In many cases you have an automated (computer assisted) regression test suite on system level that can be utilized for quickly verifying the bug fix and its surroundings.
* Changes to requirements are more welcome today (in many agile development methods), and late changes are seldom seen an obstacles for the project.
* On many places, the build process is smooth and flexible which enable you to do the steps above without putting in too much effort. And you can even build test builds that are exactly similar to an official build.
I have been involved in including bug fixes illegally, guerilla style, just because the team honestly believed that the fix should be included. We knew what the bug was all about, we had a fix ready, we had unit tests for it, we had reviewed the code, we had tested it on system level, the risk was low; the cost was low, the impact on other functionality was low, etc. But on the show-stopper meeting they decided to not include it because of “no changes in this late stage…”
The team thought they cared about customer-perceived quality, and they work hard to satisfy the current procedure and guidelines. But in the end they thought that the show-stopper meeting just behaved silly.
The situation when the show stopper meeting decides that No bugs can be fixed, no matter what, is pointing at that they are not doing their job.
The project team has determined that the cost for fixing the bug was very low, it was so low that the fix was ready even before the Showstopper meeting were able to say No to the fix. If the Showstopper meeting is adamant about their decision it seems more like a policy decision than anything else. They might have had a different agenda.
I think you should always aim for getting all bugs fixed, but you are seldome able to fulfill that. It should be the cost of fixing the bugs that should stop you.