Delivery Strategies

Posted on by

How do you handle delivery of new features or new systems? The easiest way is to just add the new features or replace the existing system, with no transition, but this is not the only approach. We’ll consider several strategies you might use: Flash-Cut, Phased, Evolutionary, Backroom/Frontroom, and Parallel.

Flash-Cut

[Also known as big bang.]

Start with the original feature, and transform to a new version all at once.

Flash-Cut Delivery Strategy

Flash-Cut

Conceptually, this is the simplest model, but it has limitations:

  • It bets that the new way will just work correctly.
  • It often assumes that there’s no need to or possibility of transitioning back to the original.
  • It can require many separate parts to change simultaneously or in a coordinated way.

Phased

Rather than do one big “risk everything” transition, divide the delivery into phases, each part transitioning a subset of the whole thing. The subset can be based on groups of users, geography, areas of functionality, user roles, etc.

Phased Delivery Strategy

Phased

This improves on the flash-cut approach:

  • The phases are smaller bites, which usually makes them easier to implement.
  • The phases can be oriented around risk. For example, you might want to do a high-risk phase first to make sure the project is feasible, or you might want to do a lower-risk phase to ease into it.
  • Because it doesn’t happen all at once, you can adjust your approach as you go.

Evolutionary

In an evolutionary approach, start from the original version then incrementally change to the new one. You can release at any point along the way, with varying amounts of the new approach in place.

Evolutionary Delivery Strategy

Evolutionary

Tradeoffs:

  • This approach allows fine-grained transitions. For example, evolving to a new user interface over time lets people adjust in small steps, rather than being confronted with a wildly different interface.
  • The risk is somewhat controllable, by which areas you focus on first.
  • It doesn’t usually provide a good way to go backwards. (While in principle you could revert to an earlier version, it’s common for there to be multiple parts, of varying desirability, all evolving at once.)

Backroom/Frontroom

The approaches described so far typically assume you’ll deliver things in the order they’re developed, but that’s an artificial constraint. Tom Gilb describes backroom/frontroom by analogy with a restaurant: the order in which chefs start or finish your dishes can be different from the order in which they’re delivered to your table.

In the backroom/frontroom approach, you develop features over time, but deliver them at a steady pace. Essentially, you’re creating a buffer to smooth out variability.

Backroom/Frontroom Delivery Strategy

Backroom/Frontroom

One of my favorite product managers was expert at this. The product targeted 3 separate markets, and she was careful make sure that each release included at least one major feature for each. She did this by a combination of holding back some features, and taking care in scheduling new ones. In this way, she made sure no release made any market feel like, “They don’t care about us any more.”

Tradeoffs:

  • Delivering at a steady pace (even if development is more chaotic) can make customers happier – they feel like things are improving all the time, rather than “feast and famine.”
  • “Holding back” can make customers feel manipulated. (“I know the feature I want is ready – why won’t they give it to me now?”)
  • It adds complexity and overhead: you have to manage more things in flight, respecting the distinction between the two rooms and making sure that features you’re releasing don’t depend on any you’re holding back.

Parallel

For a parallel release, develop the ability to run both the old way and the new way, then control the transition from one to the other.

Parallel Delivery Strategy

Parallel

Why do this?

  • If you’re doing direct replacement of a system, you may want to run both the old and new systems so you can make sure they get the same answers.
  • If you have two versions of a feature (or wording on a page, etc.), having them available in parallel lets you do A/B testing to decide which is better.
  • If you’re worried about performance, usability, etc., the ability to release in parallel lets you gradually phase in the new version so you can monitor its impact.
  • If for any reason you need to fall back to the original, the same mechanism allows that.

Tradeoffs:

  • It is more work to maintain two versions in parallel.
  • It introduces runtime overheads.
  • You have to develop some sort of feature toggling system to control who sees what.
  • If you’re running the two versions so you can compare results, you have to develop a system to do the comparison, and have a way to decide which differences are significant.

Combination

These strategies are not all-or-nothing: one release might mix any of these approaches. For example, you could combine the parallel and backroom/frontroom strategies.

Conclusion

The simple flash-cut strategy is easy, but you can improve flexibility and better control risk by using a variety of delivery strategies.

Resources