What Lifecycle or Agile Approach Fits Your Context? Part 4, Iterative and Incremental but Not Agile Lifecycles

Which levers does your team need to manage risk in your project?

Do you need to cancel the project if you can't finish a phase? You might not have the time. You might not have the ability to do this project. That's the point of Serial lifecycles in Part 1.

Maybe you need feedback from customers. That's why you might choose an Iterative lifecycle in Part 2.

A third option is to release shorter increments of value. That's why you might select an Incremental lifecycle as in Part 3.

And, teams can combine any of these options in their own iterative and incremental lifecycle. That's the point of this post.

Isn't every iterative and incremental approach an agile approach? No.

We often hear agile approaches are a mindset. A change in mindset might be true—and it's not enough.

An agile approach requires a change in culture at the team level, at the portfolio level, and in management. Agile approaches change what we discuss, how we work together, and what we reward.

That's why I too often see teams say, “Agile doesn't work for us.” If you can't change your culture, no, an agile approach won't work for you.

Not all iterative and incremental approaches create an agile culture. However, they might be better than what you're doing now. (Especially if you think your agile approach is not working.)

Let me explain more about the combo lifecycle from the first post in this series.

How “My” Combo Iterative and Incremental Lifecycle Works

As I said in the first post, I often used this combo lifecycle to create successful projects.

We did an initial pass at requirements. I often timeboxed that requirements time to two weeks.

Why? Because we were more likely to get the most important requirements in those two weeks. The longer the requirements “phase” continued, the more likely we'd have a wish list way too long to implement.

Then, we moved into prototyping features. This was an iterative phase. We got feedback from someone—not always a customer—during that iterative phase.

Then, we fully implemented three features as an incremental phase. (Not the entire feature set. Often, the happy path through the product.) Why three? Because that implementation was often enough to see where we would have more risks. Did we always surface all the risks? No. However, we did find many of them.

Then, we had a formal review of the architecture and the risks. If we thought the risks were low enough, we might release what we had so far. In my experience, while we had enough prototypes to understand the risks, we didn't have what we would call an MVP now.

Then, we moved into more of a staged delivery approach. Because we finished features, we could release whenever we wanted to.

It wasn't an agile approach even though it was an iterative and incremental lifecycle. We didn't do these things:

• Have one product person who guided us.
• Decide on the next piece of work based on risk, not on value.
• Ask customers for feedback. We mostly demonstrated to management and other internal people.

However, “my” combo approach is iterative and incremental.

There are other iterative and incremental lifecycles, such as Basecamp's Six-Week Cycle.

Basecamp's Six-Week Cycle

Do read The Six Week Cycle. Notice what occurs:

• Some people prepare the work for a team.  They call this “scope hammering” to determine something useful that a team can deliver in 6 weeks. That's iterative work.
• Then, the team delivers work during that 6-week cycle. The team delivers an increment of completed work.
• If the team realizes they can't deliver everything in 6 weeks, the team adjusts the scope.
• Notice they say that how a team delivers is up to the team.

I suspect each 6-week cycle is different for each team and what they work on. Some teams will need to iterate on the requirements so they can finish something useful in 6 weeks.

If you read Cycles, you'll see that testing appears to be separate from development.

While this is a lightweight approach, I don't consider this an agile approach. Here's why:

• The people doing the work receive the work from the people who hammer the scope. They don't collaborate.
• Testers (from my reading) appear to be separate from the developers.

I'm not saying their approach is bad—on the contrary, it appears to work quite well for them. It's a lightweight, iterative and incremental lifecycle.

There are other iterative and incremental lifecycles that don't have names, either.

Other Iterative and Incremental Lifecycles That Are Not Agile Approaches

I've seen these:

• Waterfalls inside timeboxes
• Different varieties of iterations and increments
• Release trains

I'll explain each of these.

Waterfalls Inside Timeboxes

I often see waterfalls inside timeboxes. The architect takes several requirements, does the analysis and high-level design. Then the developers write the code. At some point, the testers test.

While the people work inside a timebox, there's little collaboration and very long feedback loops. I wrote about this in How Long Are Your Iterations? Part 1. This approach might be better than what you're doing now—although it's not an agile approach. (I wrote more about some of these problems and how to solve them in Create Your Successful Agile Project.)

Varieties of Iterations and Increments

I wrote a story about one client's iterative and incremental approach in Iterations and Increments: For Any Project.

Notice that Dave's project iterated over prototypes to reduce risk. Then, they developed tests to verify the first “mini-release” would work. That's an increment of value. They released another increment, and then returned to prototyping, followed by another increment. Then, they “finished” the remaining features with their combination of iterating over the requirements and one final release as an increment.

There's no name for that approach. It's iterative and incremental. It's certainly a light-weight approach. I would not call this an agile approach.

Release Trains

Release Trains are another iterative and incremental lifecycle that I don't consider an agile approach. I've written extensively about release trains, in Manage It!, Using Release Trains to Get on Track, and in Not Ready for Agile? Start Your Journey With Release Trains.

Summary of Iterative and Incremental Lifecycles Without Agility

These roll-your-own lifecycles help teams use the ideas of iterating over feature sets and incremental releasing to manage their risks. However, they don't specifically manage WIP, encourage team-based collaboration and decision-making, and much more that agile approaches do.

I'll address the agile approaches in the next post and explain why the agile approaches change the culture—if you really use them.

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