This morning the ‘key release dates’ for the remainder of the 2008 arrived in my inbox this morning. This got a chuckle out of me for a variety of reasons, but at the same time the following thought crystalized: Are pre-defined release dates bad for Quality?.
With a bit of prompting by the other Adam in Toronto who tests here are some points to back up this position:
- leads to release date backwards schedule planning (test invariably gets squished)
- assumes only the happy path through the schedule
- no room for learning about the feature
- how do you calculate effeciency improvements based on familiarization?
- creates artifical internal timelines (what if uat only takes 3 weeks, but we have 5 on the schedule)
- leads to monolithic thinking (we dont need to have a working build for 3 weeks yet according tot he schedule)
- rather than having the product dictate where we should test (bug clusters, code churn, technological risk, etc) often will concentrate on things that will achieve the schedule — which might not be the same as effective or appropriate test selection
Now, I know there are lots of things to coordinate around a release and that having a pre-defined date helps coordinate and plan those things. I’m just throwing the idea out before I lose it.
Adam, your points are only true in a waterfall lifecycle where the PM does no risk management (ok, that’s true for a lot of projects).
Your points are not true for an agile lifecycle. They don’t have to be true for an incremental lifecycle. Depending on what happens to test, they may or may not be true for an iterative lifecycle.
It all depends on how you’ve organized the project–the whole project and the testing part of the project. The lifecycle does matter.