What Lifecycle or Agile Approach Fits Your Context? Part 2, Iterative Lifecycles

Back in Part 1, I wrote about how stage-gate approaches were as agile as we could use at the time. We had one delivery, so our agility was about canceling the project if we couldn't finish it.

However, some smart people also realized that we had another lever, aside from estimation, to replan the project. We could get feedback on prototypes—from the customer. That feedback would allow us to replan.

The Spiral Model

Barry Boehm developed the spiral model. This image shows several ideas:

• That we use prototypes to reduce requirements risks.
• We develop test plans early.
• That we use prototypes to inform the detailed planning, design, etc.

The spiral model assumes that if you get feedback early enough, you've managed the technical and requirements risks.

I tried to use the spiral model once, on a short project. I had to explain to my managers how the project would work. My managers were smart but didn't understand how to spiral time. To be honest, neither did I.

I showed them this Spiral Life Cycle picture. They understood that picture. We had choices:

• How many features did we want to prototype?
• How long did we want to spend prototyping?
• Did we plan to throw away the prototype?
• Who would offer us feedback?

I was on that project with two other people.  We divided the three feature sets among us.

We spent the next three days prototyping a single feature from our feature sets. Good thing we didn't spend longer than three days each on the initial prototyping. Each of our prototypes worked alone—they didn't work together.

However, since we did manage to minimize our prototyping time, we learned from that experience. We worked together for the rest of the prototyping. We took one feature set and finished it. Then, we took the second feature set and finished that one. Same with the third feature set.

Our project turned into Evolutionary Prototyping, another iterative approach.

Evolutionary Prototyping

In the spiral model, we used the entire project's requirements to refine the requirements.

In Evolutionary Prototyping, we develop the initial concept—not all the requirements.

We use the feedback to inform more of the project's prototyping.

In Evolutionary Prototyping, you don't wait until the end of the entire “project” to refine the prototypes. If you get feedback as you proceed, you finish the design, coding, integration, and testing. Then, because you're iterating over the feature set, you're only supposed to need a little integration and final testing at the end.

My project sort-of worked like that. We had more feedback cycles to refine that initial concept:

We didn't just refine the previous prototype—we refined the initial concept. The blue lines are the feedback we expected.

Once our customers saw demos, they wanted to change things.

I know, what a surprise.

The real issue was the long red feedback line I labeled the Project “Kiss of Death.” One of the customers realized he wanted something different—something we didn't expect for this product.

We had to decide what to do: cancel the project because it was not what this customer wanted? We asked other customers and delivered this project. Then, we got to work on the next project for that customer and others like him.

RUP is also an iterative approach.

Opportunities for Agility

The iterative lifecycles offer agility anytime you get feedback from a customer (or a manager). That means you can replan the project or the product.

You can re-estimate and replan, also. That means management has options for what to do about this project in the project portfolio.

The one issue I have with iterative lifecycles is the fact that we have one delivery at the end. All the iterative lifecycles assume there's one delivery at the end. (You might make the project shorter, but you still have to finish the work. Iterative approaches leave finishing to the end.)

However, because you see prototypes, you can:

• Replan the sequencing of the prototypes.
• End the project earlier.
• Decide earlier if this is the right approach to solving this set of problems.
• Test the prototypes with the customer. Or, obtain customer feedback.
• See the product come together, depending on how you approach the prototyping.
• Manage customer risk.
• If you're careful, you can manage the technical risk, of an insufficient architecture, too.

So, more agility than a serial approach.

However, because you're not implementing all the features at one time, you can decide how to rank and sequence the work.

Iterative Lifecycles Need Cross-Functional Teams

Once we leave the realm of stage-gate or serial lifecycles, projects benefit from cross-functional teams. We need designers, testers, anyone aside from developers to develop the prototypes. If you use a spiral model or RUP, your managers might decide to phase various people onto the project.

However, if you use cross-functional teams, Evolutionary Prototyping shines as a way to reduce risk, especially if your company can't develop and maintain an agile culture.

The next post is about incremental lifecycles.

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