Earlier this week, I was at SPC teaching about project requirements and project management. If you haven’t thought about lifecycles, consider the differences between these kinds of lifecycles:
- Linear: Waterfall and waterfall with feedback
- Iterative: Spiral, where the whole product is up for grabs each time
- Incremental: Where you add to the product in pieces
- Agile: cycles (iterations) of chunks (increments): Add to the product in pieces, where each iteration you can deal with the whole product.
- Random: code and fix
If you’re building a tangible product, you can use linear or an iterative lifecycle. In an iterative lifecycle, you’d iterate on prototypes, and then engineer the entire product at the end. If you’re building a software-only product, iterative lifecycles can be difficult to complete. Too often, sponsors or management pressures the project team into releasing before they’ve engineered the whole product.
Incremental lifecycles are fabulous for software projects, and they are particularly wonderful for short projects. I’ve used incremental lifecycles for release trains, see this paper and this article.
But sometimes, you have a longer project and you can’t define the whole architecture up front (or you don’t want to). That’s when the agile lifecycles shine. You can use agile lifecycles any time, but many senior management teams (and project managers) are still unsure of them and aren’t clear how to use them. You define the set of stuff you want in the project in this iteration, and then proceed with this iteration. You don’t change the requirements in this iteration (and you continue to re-clarify the requirements for the next iteration). Within an iteration, you work on chunks of the project, not prototyping, but completing the product. If you have to change the design or architecture, that’s ok, you do it. Since you’re not working on *everything*, it’s possible to change the design and not kill the project.
Random lifecycles such as code and fix are a disaster. They don’t work. Don’t use them.
Once you’ve got your head wrapped around lifecycles, remember that different parts of the entire project can have different lifecycles. If you’re doing an iterative lifecycle for development, the testers can still use an incremental lifecycle. It’s harder to plan, but if it works, that’s all that matters, right?