Three Ingredients For Great Software Releases (But You Only Need to Pick Two)
Submitted about 5 years Ago
The more I code I write, the more it seems that planning software releases can be such an inexact science. The irony of this is not lost on me. Even if you have a deep understanding of your code base, are doing all the right things with Agile and TDD and CI and all those, circumstances inevitably arise that that make reality different than expected. Implementing that seeingly simple button. One of your data feed providers changes their format unexpectedly. Deserializing large amount of data from a JSON file that causes memory issues, requiring handler code that now needs more tests written ... and you likely can add many examples of your own.
This variablity in software development timelimes is completely at odds with trying to run a business and having customers and investors with whom you need to communicate expections. But what can you do? How can you reconcile these disparate pieces?
Many software release planning discussions I have been part of tend to go in circles. If you need a firm release date, engineers aren't sure if they can deliver the required features, since they have not yet written that code. This results in a tendency to commit to a date needlessly far in the future. Later, testing often surfaces new bugs that need to be addressed, which takes more time. There are many possible scenarios here that will mess with your well-intended planning.
"Three possible variables, pick two"
The goals of every software project can be stated in three simple variables:
1) Time - When it is released into production.
2) Features - What it includes, the use cases that are delivered.
3) Quality - How many bugs it does not have, throughput, data accuracy, uptime - or however you define quality.
First, you define what each of these variables mean in the context of your project.
Next, you choose upfront which two variables are the anchors, and which is the floater. Discuss this with your team.
Here are some examples:
"We know what the market needs for features which also includes a high level of quality which we can define. Let's get this released in about 6-8 weeks, as soon as we meet the feature and quality goals." (Anchor on: Features, Quality; Float on: Time.)
"We have to get something to a customer asap, and we know we need continued high quality as a production product, so we're flexible on how many of the features that get included." (Anchor on: Time, Quality; Float on: Features.)
"It's a beta product, so users are forgiving on quality, we just want to get something into users hands so we can get feedback." (Anchor on: Time, Features; Float on: Quality.)
What if you feel the need to anchor on all three variables ("We need to release X on Y date which includes Z")? This is really tempting. DO NOT do it. This is a recipe for disaster.
Every software project can be framed with three simple variables - Time, Features, and Quality. Your software releases will meet your expectations more often when you define these upfront and select your two anchor variables, with the third as your floater.