« TDD Survey Results | Main | Inline Assertion Templates for Eclipse »

08/20/2009

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e54fb013da88340120a508dca1970b

Listed below are links to weblogs that reference You're Already Using Continuous Flow (poorly):

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Urs Enzler

I do not really agree with what you describe here.

In my team the scenario would look like this:

1) day 1 sprint 1 -> add bug

2a) if it is really a critical bug that breaks existing features then it is very likely that it gets detected during in-sprint testing -> immediate fix within sprint 1 => delivered within 1 sprint (= 10 working days in my project)

2b) the bug remains undetected and is detected early in sprint 2 -> defect is prioritized high on the CURRENT sprint backlog (we always save some time for defects [critical or not] in each sprint) => defect fixed end of sprint 2 (= 20 working days)

- no late working
- no long delay

The reason why I'm against more "releases" (or product increments) is that our customer and the release testing team can not cope with such frequent releases (installation on several machines, on several sites wordwide).

Of course, from time to time there is the need for an immediate release that fixes an issue but this should be really rarely. So far it happend once in 2 years of development in my team.

Cheers,
Urs

Ben Rady

Urs,

Even if you add the defect to the sprint 2 backlog, you're still delivering a fix 60 days after introducing it. Of course, we all do exploratory testing to try and find bugs but some of them can only occur "in the wild". You have to release to find them.

I'm surprised to hear you say that you're "against" more frequent releases. Do you think they're inherently bad? Or just not your team wants to do? What if your release testing team could verify a new version in 30 minutes? What if installation and deployment to customer sites was automatic? What would be the downside of releasing more frequently?

Urs Enzler

> Even if you add the defect to the sprint 2 backlog, you're still delivering a fix 60 days after introducing it. I'm surprised to hear you say that you're "against" more frequent releases. Do you think they're inherently bad? <

Not inherently bad, but there is a point where delivering a new release does not outweight the benefit of it. If the ROI (Return-on-Investment) is given for a release then it's okay for us. However, this is normally not given for an intermediate release.

But again, we have to distinguish between fixing an issue on a already released version and a bug introduced on the development trunk that is not yet released. The ROI is totally different in these scenarios.

In my project a product-increment is quite costly to deploy to the customer (several sites, worldwide, specially set-up computers), each has to be verified. And finally a real release (goes to the end-customer) has to be validated by the FDA.

The comments to this entry are closed.