Release Strategy

My specialty is custom application development. With hard work, some great teams, and a little luck, I've had a long run of success since my embarrassing disaster long ago. One key part of this success is release strategy: (1) breaking releases into right-sized increments, and (2) wisely selecting the content of those releases.

Example

Digging through some project notes, I found a great table that succinctly describes a release strategy.

Release	New Technology	New Business Functionality
r3	new SSL network stack	company registration
r4	e-forms w/markdown	e-filing
r5	accounting integration	e-receipting

Release Guidelines

Planning a great release is hard work. You have to make tough choices. How large should the next release be? What business functionality should be next? How can we implement that business functionality in valuable increments? How can we minimize the technical risk? How can we do all of this in such a fashion that we set the stage for the next release?

Here are some guidelines I like to use:

• Limit release length to (3) months;
• Limit release scope to (6) user level use cases (see example);
• Select use cases with high business value;
• Focus release on one functional area;
• Introduce (at most) one major new technology; and
• Set the stage for the next release.

This is a large release. The number of use cases will double when you work through their variations and failure handling. So don't add more.

And finally, remember that the standard rules apply for that new technology you're excited about: Use Proven Products and No Plumbing.

Lesson Learned: Strategically roll-out large applications as a series of right-sized high business value releases.