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
An incremental approach starts with some requirements gathering and refinement. Then, the team (or whomever) creates an architecture.
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
Design to Schedule asks us if we want to release. Staged Delivery assumes we will release.
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.”
This series:
- 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
We used Staged Delivery as described by McConnell to write software for medical devices in the 1990s. Rather than releasing to end customers at the end of each increment, we did a pretty realistic integration with hardware in every increment. Some of the increments went to external alpha or beta test as well. We found the Staged Delivery to be a considerable improvement over stage-gate waterfall for two reasons. The first – predictability. After about 1/3 of the increments were finished, we had enough velocity data to predict what we could realistically finish in the remaining 2/3 of the schedule. The second was fewer late-found quality problems. Most of the defects were found during the increment in which they were created or quite soon thereafter – while I still remembered the details of what I’d been doing.
Not agile, certainly, but reaping many of the benefits of the short feedback loops.
The top thing I’d change if I went back – put the increments on a cadence!
I suspect that many of us who had successful projects used incremental approaches. I suspect that your predictability was a function of risk assessment and an intuitive idea of cycle time.
I used Staged Delivery and Design to Schedule in the 80s. I didn’t know the names for them, but they worked. Yes, I agree about the increments in a cadence. I often asked the project teams: What can you deliver this month? That was a rough cadence and it worked quite well.
What I remember is that the features were grouped into sets or “stages” of fairly even size. Each “stage” had a target start and end, with a specified length somewhere between 3 and 6 weeks. After 6 months or so, the number of completed stages (feature sets) wasn’t on target. I remember making a simple graph showing planned completion of stages vs actual. We didn’t call it throughput, but that’s what it was. We realized that there was an average time to complete a stage – now I know that’s the cycle time. Simple math to see that we needed to drop the last three stages in order to hit the target date.
The key to the whole thing was, as you said in this series, the concept of “done”. McConnell’s book said we should have a shippable product at the end of each stage. We couldn’t think of any way to define the stages to be literally shippable on a mixed hw/sw medical product, but did our best to make every stage deliver actual usable features and reach shippable quality each stage. The first six months we got a lot of pushback over “repeating testing unnecessarily” with all the regression testing, but the pushback evaporated once it was visible that we were reliably delivering usable features on a predictable rate.
The variable stage lengths were messy though – cadence would have reduced our overhead.
I think you used the idea of Design to Schedule with your throughput calculation to hit the target date—smart idea. That pushback against testing? Not surprising. And, since you had completed work, you had all the ammunition you needed to keep testing.
I still have trouble with variable stage lengths. I think in weeks or months. I suspect I’m not alone. That’s why I used a monthly cadence. In my experience, a cadence longer than a month allows people to work on not-this-project work. That prevents anyone from meeting the date with a working deliverable.
Done matters! (I should check the last post and make sure I wrote enough about that.)
Pingback: Five Blogs – 28 October 2020 – 5blogs
Yes, we started with staged delivery and ended up doing design-to-schedule. The next project was more intentional about design-to-schedule and didn’t even commit to the last few planned stages. The variable stage length was just because we didn’t know any better. I agree that a regular cadence is much better.
The key to the whole thing, though, was “done” – integrating every stage into the overall product and ensuring it was fully functional & non-functional requirements were met before going to the next stage. We did spend more time spent doing regression testing than in waterfall, but it was more than offset by less time spent debugging problems that had been introduced months earlier. That short feedback loop saves enormous time. I spent the next decade frustrated because agile authors all insisted that frequent actual releases were critical to agile, when I’d seen such huge improvements without any actual releases.
Then finally was introduced Reinertsen’s work and realized that reducing batch size from 18 months to 4-6 weeks had caused most of the improvement AND that the iterative approach is great when customer requirements are very fuzzy, but the requirements can be more or less fuzzy depending on the field. In the project above, customer requirements were fairly knowable and alpha & beta testing was planned to discover the rest.
Yup, you had an incremental approach—and I bet an iterative approach for the next chunk of requirements. And, because you got to done for each stage, you reduced your cycle time. You managed WIP, which was critical for both your projects and mine.
You might not have read Part 7 yet (I wrote “too much”!). In that part, I have a picture about the relative determinism of the problem. If your requirements are not going to change much, you’re on the left side of that continuum. If you expect the total project duration to be longer than 2-3 months, then an incremental lifecycle works, as you found.
Even if you don’t expect customer-realization (“I need something different”), the longer the project takes, the more you might need to iterate over requirements, even as you release increments of finished functionality. Because you got to done, and because you were able to use alpha and beta testing as (later) feedback loops, and you probably didn’t find much to change, a more incremental approach worked fine.
I am pretty sure that many of the early agile projects were for IT, the customer down the hall. Those were the projects where the customer said, “You gave me what I wanted, but it’s not what I need now.” You and I worked on different kinds of products.
First, you and I worked on products. We knew they were products. They were not “systems” or “applications.” We used product thinking.
Second, you and I knew that when we released, the company made money. I’d been part of too many “we won’t pay for this” conversations when I started to use staged delivery. While some IT projects still do charge-backs, that’s not how the company makes money and pays its employees. That certainly changed how I thought and helped my managers understand the value of done, as release criteria.
Yeah, you and I have similar experiences and that does not match the original problems the Manifesto authors had to solve.