Cohesive Releases

Image credit: http://www.flickr.com/photos/dystopos/ (CC BY-NC 2.0)

Lately I’ve been kind of obsessed with the idea that releases should be highly cohesive, delivering features and functionality that “go together.” I’d like to explore (key word there) how this concept works over the course of a few posts.

All too often I think we get sucked into the trap of thinking a “release” is synonymous with a “duration.” That is, releases are principally defined as disparate work completed in some bracket of time. We might visualize a release as a list of work and a bar on a calendar spanning a number of days, in that we have a “quarterly release” or a “bi-weekly release” or a “bi-annual release” and the like. Either way what we’ve been calling a release may include disparate new functionality serving disparate personas and motivations.

Date durations have a start and an end. There is absolutely no reason we need to start release in the same duration in which we end a release. In fact, if we’re trying to make an important deadline we really only need to answer the question: “when do we have to start this to get it done when we need it?”

I believe in planning, designing and implementing around big blocks of common functionality and I have seen this work rather well. A few questions we can ask ourselves to make sure we’re finding a meaningful shape for our release:

• What stories fit together or are dependent?
• Are we releasing a new product?
• Are we releasing a big feature for a new persona in an existing application in our portfolio?
• Are we rewriting some existing functionality to pay back technical debt and pave the way for some strategic initiative?
• Are advancing our platform?
• Are we doing an aesthetic update or tweaking for search engine discovery?

I’m not arguing against keeping a cadence of regularly dropping software. Periodic and predictable shipments are often very valuable (sometimes even required). After all marketing, sales and customers have their own sustainable pace to maintain and incorporating software modifications into their own planning processes isn’t necessarily core to their mission. It is possible to overwhelm people with a high-throughput, flow-based development system.

One benefit of planning around cohesive features: we can select appropriate methods and practices for a concept I like to call a “mission set.” But before I get into that I’m going to cut this post here; it’s getting a bit long.

In the next installment I’ll dive into the “mission” and “mission set” analogy and, hopefully, uncover some of the benefits we receive in planning and executing highly cohesive releases.

Tagged as: agile, opinion, Planning, Practices, release planning