So far, we've discussed the lever of canceling a project at any time with the serial lifecycles in Part 1. That's assuming you replan and/or cancel.
We added another lever of looking for more feedback with iterating over the requirements in the iterative lifecycles in Part 2.
Teams have another lever. They can release increments of value. That's what the incremental lifecycles offer.
Notice that the serial and iterative approaches all assume one delivery at the end of the project. The incremental approaches offer multiple deliveries throughout the project. And, because these lifecycles offer deliveries, you have the option of canceling the project after any specific delivery.
Teams can get some feedback from one feature set to inform the next set—but that's not a primary lever. That's because these lifecycles normally complete one feature set at a time.
I know of two primary incremental approaches: Design to Schedule and Staged-Delivery.
Design to Schedule
Once the team has an idea about the architecture, the team starts working on the highest priority feature or feature set.
The feature sets take whatever time they take. Each box in the image has a different width, corresponding to the relative time the feature set needs.
Once the team completes that highest priority feature(s), the team can release the product. That's why this lifecycle is Design to Schedule.
What if the team runs out of time or money (schedule)? Release.
Of course, there are feedback loops here, too:
Notice that we expect feedback from later features back to the previous features. However, if we have “bad” feedback from the last (or interim feature), we don't have the “Kiss of Death” as we did in the serial or iterative lifecycles.
We can stop the project any time the team completes and releases a feature set. That's the beauty of incremental lifecycles.
When we release, we can regroup and figure out what to do next for this product. We might:
- Iterate over more prototypes, in another project.
- Fork another product. (I did this with several Lite vs Pro products using this approach.)
- Use a timeboxed set of experiments to decide what to do next. I often used iterative approaches to experiment before starting another project.
Once you release the product, you have many more options, for the project, for the portfolio, for the organization.
Design to Schedule isn't the only incremental lifecycle. Staged Delivery has its own set of benefits.
Staged Delivery starts with gathering requirements, in whatever way we choose. Someone ranks the feature sets. (In the olden days, the project manager with the help of the team ranked.) The team chooses the most appropriate architecture, based on what they know.
Then, the team delivers a feature set. In Staged Delivery, the team delivers that feature set. Do you want to stop the project? You can.
If you want to keep going, the team works on another feature set and delivers it. Release.
Continue implementing by feature and releasing. When you get to the end of the project, you might have some final integration and test, but that's a short duration.
Staged Delivery has feedback loops, too. We expect the normal loops in blue. And, because we released the previous feature set, we always have something that works. That product might not be everything the customers want, but it works.
What happens if you get that red feedback loop, especially near the end of the project?
Release what you have. Figure out what to do next, as we could in Design to Schedule.
Opportunities for More Agility
Because we release every time we finish a feature set, we have these opportunities for agility:
- Re-rank the remaining feature sets. We might choose to do Feature set 1 and then feature set 3. We decide to implement Feature set 2 later.
- Release as often as we have finished features.
- End the project whenever we want to. (This addresses schedule risk.)
- Gain early insight into architectural or other potential product risks.
- See and demo the product as it grows.
- Manage the project portfolio more easily because the project releases value more often. The people who make the portfolio decisions can decide whether to continue on this product or ask the team to move to another product.
The more releases we have, the more options we have.
Incremental Lifecycles Need Cross-Functional Teams
Just as the iterative lifecycles, incremental lifecycles require cross-functional teams. You can't just have developers, then testers, etc. The team works together. That's how you get to release every feature set.
Especially with cross-functional teams, the incremental lifecycles reduce risk. You can see the product as it evolves. You keep the product “clean”—for example, maintaining the tests so you can release as often as you finish a feature set.
If your company can't create an agile culture, consider an incremental lifecycle, especially if you have schedule risks.
Next, I'll discuss iterative and incremental lifecycles without being “agile.”
- What Lifecycle or Agile Approach Fits Your Context? Part 1, Serial Lifecycles
- What Lifecycle or Agile Approach Fits Your Context? Part 2, Iterative Lifecycles
- What Lifecycle or Agile Approach Fits Your Context? Part 3, Incremental Lifecycles
- What Lifecycle or Agile Approach Fits Your Context? Part 4, Iterative and Incremental but Not Agile Lifecycles
- What Lifecycle or Agile Approach Fits Your Context? Part 5, Origins of Agile Approaches
- What Lifecycle or Agile Approach Fits Your Context? Part 6, Create Your Agile Approach
- What Lifecycle or Agile Approach Fits Your Context? Part 7, Lifecycle Summary