Microreleases

In my pet project Bumblebee, I started out planning releases in a traditional agile way; small batches of features I wanted. I was spending a lot of time moving features in and out of releases, even features that I still haven’t implemented. I also had some very long release cycles, with a maximum of some 4 months where I didn’t release anything, just because I wanted to finish the batch! All of this because of… yeah, why did I ever do that? I was mesmerized by “The Scrum” having me planning and committing to these batches of work that I rarely completed and changed all of the time. How wasteful!

After a few releases (and in the end of the 4 month “sprint”) I saw that Joshua Kerievsky was about to talk about microreleases at Agile2008 , and it struck me as exactly what I wanted.

After that I simply just did one important feature at a time, and then I released it. Very simple. Things now work smoothly. It feels very good. No more wasteful planning. I am a happy puppy. Microreleases!

Consequences

The inevitable consequence of this is that the “iterations” have variable lengths, since the features are of variable complexity. This will impose requirements on the organization regarding customer availability, release organization, environments, marketing and more, but in my eyes, this is an opportunity to improve. In my case with Bumblebee that was not a problem since I was the organization.

Another consequence is that there is not room for “I’ll fix the [insert things like test, refactoring, documentation] before the release” because there is no such opportunity! Every thing has to be “done-done” all the time.

Kanban and pull systems

This idea is basically the same as that of a true, minimal batch, kanban pull system; you pull a feature at a time and release as soon as the feature is done. Note that kanban and microreleases are NOT the same as having short, but fixed length, iterations.

So, what about estimating and planning?

The best is if the entire organization can be triggered by the microreleases, e.g. setup-times are minimized across all functions to enable the shortest concept-to-cash cycles possible.

If that is not feasible, I have two ways of looking at it:

One is that if you are estimating without historical data, you will have to pick a qualified wild guess (also called “gut feeling”) and then correct as you go along. There is no such thing as “committing” or “promising” to do things that are further away than a day or two. What you can promise is to work as effectively as you can and constantly report progress to enable correction. Microreleases provides such progress data very soon.

The second is that if you have some historical data, and if the features have been broken down to an understandable level, you can just do an average over time and that will provide you with an good enough estimate, which will have to be corrected just as for the previous case.

The shift

I think that the agile change from single-big-bang-monster-releases to short iterations and small increments was the most important one, but the change from a fixed iteration to a flow/kanban/pull/microrelease development cycle will have a bigger impact on how we think about software development.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: