Comments on: Decisions around the product release – part 3 http://thetesteye.com/blog/2009/04/decisions-around-the-product-release-part-3/ by rikard edgren, henrik emilsson, martin jansson and friends Thu, 19 Aug 2010 13:06:15 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Martin Jansson http://thetesteye.com/blog/2009/04/decisions-around-the-product-release-part-3/comment-page-1/#comment-115 Martin Jansson Tue, 21 Apr 2009 08:45:40 +0000 http://thetesteye.com/blog/?p=266#comment-115 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. 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.

]]> By: Henrik Emilsson http://thetesteye.com/blog/2009/04/decisions-around-the-product-release-part-3/comment-page-1/#comment-114 Henrik Emilsson Tue, 21 Apr 2009 08:15:15 +0000 http://thetesteye.com/blog/?p=266#comment-114 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. 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.

]]>