The customer doesn’t want a release every month

Comments (2)

Print This Post Print This Post

Email This Post Email This Post

Permalink

This is part 4 of 10 Pitfalls of Agility on Large Projects. In part 3, we talked about how we can’t afford to trust everyone on large teams, and what to do about it.

Frequent releases, which are central to both agile and lean methods, sometimes draw a visceral reaction because people fear we can’t keep the product that close to release quality at all times, while still delivering as much innovation.

That is a real challenge of agile/lean methods. But making this argument against short cycles is difficult, so the most common argument ends up being “the customer doesn’t want a release every month (or every 6 months, or every year …) anyway.”

Unfortunately on any project with many customers, while no customer wants a release every month, there is always one wanting a release right now.

We can deal with that to some extent by having tiers of releases: the single-customer quick fix, the multi-customer patch, the service release, and maybe minor and major releases. But each of these tiers involves extraordinary cost and waste from duplicate efforts — waste that can often be avoided if the main release cycle is short enough that customers can get their needs met.

It’s better to embrace the challenge and compelling benefits of feedback on short cycles. Here’s a rough diagram of a typical three-tier set of daily, weekly, and monthly release cycles.

Release Early and Often

The heart of it is a per-change or, at worst, a daily build (continuous integration). This build is picked up only by people who are in close contact with the project. This discipline keeps everyone in sync, and keeps the project from wandering into a broken state.

The weekly build (or some equivalent) is important whether at a large organization (where many remote teams share dependencies) or at a smaller startup (where the salespeople and management interact with the product daily). Tightening up the feedback loop of these internal customer proxies creates transparency, builds trust, and keeps the product from evolving off-track feature-wise.

Releasing something to customers every month can seem daunting in some large organizations. The biggest of the software beasts (Microsoft) has had challenges but also great benefits in doing so. And if you think you have a great plan set in stone (a very detailed set of requirements), all the feedback these releases will generate would seem to be just a source of endless distraction.

Don’t be foolish. Unless you’re delivering a 1-1 functional replacement for some existing product (and how often do we do that?), you desperately need that feedback. It keeps the team connected with the customer, motivated by the customer, doing right by the customer. Concerned about opening your kimono to competitors? Limit your audience to a trusted subset, like Apple’s AppleSeed program and most others do.

Once the team gets used to a cadence of regular releases, the practice becomes the heartbeat of the organization, keeping everyone on track, in touch with reality, and constantly learning.