Once you’ve delivered products in a couple of different organizations, you’ll notice that Release Management becomes a major headache and sticking point that will be debated ad nauseam. I’m here to tell you that it’s going to be painful no matter where you go…but, there are specific capabilities to build that can help you maintain velocity without sacrificing quality.
Let’s go!
In its simplest form, a Software Development Lifecycle involves these steps:
- Decide what to build
- Build it
- Deliver it to customers
- Tell people about it
You will have to maintain the product after release, but we’ll focus on everything up to that point. You can even rearrange the steps, but you have to do all of them at some point. Instead of treating each step as a check box that you complete in a specific order, it’s better to think of each one as a bucket to fill.
If you want to be cautious, you might fill them like this:
- You decide a lot of things up front. This gets documented in your as-designed state.
- Then you start building only when your as-designed state is locked in.
- You finish building something entirely, and then you lock in your as-built before you deliver it.
- You tell customers what you’re going to give them only after it is built, and you gradually tell them more as you release the product from test environments into production.
This style of development prevents design changes after building has started, and it eliminates the possibility of telling customers something about the product that is not already in the as-built. This looks like the playbook of a consumer hardware business with outsourced manufacturing.
Now, if you’re an enterprise SaaS business, your customers are going to push you to tell them more about the product before it is built.
Your process might look like this:
- Here, you decide a lot up front.
- Then you tell customers as much as you can before you build.
- Then you build, and you continue to tell customers more as you’re building.
- Finally, you only deliver the product after you’ve told customers everything you’ve built, with as much accuracy as possible.
Before we run through every possible permutation, let’s think about some of the trade-offs and mechanics at play.
Every time you move information around from one process to another, there’s a small amount of inevitable loss you incur. The more information (larger scope of releases), the greater the likelihood of lost information.
Generally speaking, certain processes have to precede others, BUT they don’t have to complete all of their work before others can start. You can decide 80% of what you want to do, and leave the other 20% for after you’ve built some of the feature.
The sequence rules are as follows:
- Build starts before Deliver, & Build finishes before Deliver
Decide starts before Build, & Decide finishes before Build
and transitively…
Decide starts before Deliver, & Decide finishes before Deliver
Tell is the wildcard activity here, because you can move this step almost anywhere in the sequence. The only time tell must come before deliver is if you ship a breaking change that has no opt-in/opt-out mechanism. Then you have to tell before you deliver. Otherwise it’s just mean.
Now, let’s look at a process that is optimized for agility:
- Here, decide only narrowly precedes build, which narrowly precedes deliver.
- Tell comes in the latest.
Surely, this process only works for the tiniest startups who don’t have big, powerful customers telling them what to do, right?
Well, it turns out there’s a trick that makes this agile model work well, and that’s a hidden factor representing the population of customers you’re building for.
In every model so far, we’ve been assuming that when we decide, tell, build, and deliver, it’s for all customers we intend to serve. If we instead think about these steps in relation to a subset of customers (Beta, Early Adopter, and General Availability), then our process looks like this:
In Beta, we’re only deciding, telling, building, and delivering 30% of the total scope of what we want to do, and we’re giving it to a small Beta cohort of our customers.
The key here is that you can run these steps in parallel, and shrink your iteration time, if you build, deliver, and communicate different levels of scope to more precise segments of customers.
That’s because a smaller, more focused group of customers is an easier target to serve. They have a smaller set of requirements than your entire customer base, and there are fewer vectors of complexity to deal with.
Any quality escapes you have will be easier to spot and to remedy. The variable you can control entirely is how broadly you distribute your product across your customer base, and far too many companies rush straight to General Availability right away.
Eventually, you want to reach as many customers as possible, but in order to do that, you’re going to have to repeat these 4 steps with increasing levels of scope to serve increasingly complex needs.
You want to continue to be fast, but your speed is ultimately limited by how many iterations it takes to clear certain quality hurdles you need to serve the larger customer base, and the efficacy of each at bat is limited by how quickly your organization can learn from each release.
You need the time between iterations to be short and the quality escapes to stay flat or grow at a rate that is slower than your distribution is scaling.
Ultimately, there is no free lunch in choosing a Product Release process. There are simply trade-offs.
And perhaps the largest trade-off of a true agile model is that you give up the ability to forecast precise information far into the future.
In exchange for losing predictability, you gain quite a bit of benefits:
- The tendency to arrive faster at the solution with the highest fitness for customer needs.
- The ability to constantly incorporate new information and adapt to extrinsic changes.
- The tendency to produce smaller mistakes that are easier to recover from.
- A lower volume of wasted work, especially in the form of partially finished product that is never delivered to customers.
So why doesn’t everyone do it this way?
Because you have to learn how to whisper.
Product, sales, marketing, account management, CX, and support need to be able to communicate precise messages to specific audiences, instead of one-size-fits-all communication. This is hard.
You have to build the technical muscles to move fast without breaking everything.
You need feature flagging, automated testing, nimble documentation, and continuous integration and continuous deployment.
You have to show courage at the leadership level.
It’s not easy to say no or not yet to big customers, so you need alignment across functions and air cover from executives to pull it off.
Most important of all: you have to value final quality over initial speed.
The ultimate goal of agile is to arrive at the best solution faster through faster feedback loops.
If your organization obsesses too much over meeting deadlines and forecasting roadmap timelines, then your team will have a tendency to cut corners and deliver products that technically meet the commitments you made to customers, but they fall short of actually solving the problem and satisfying the customer.
When this happens, customers will complain about not getting things on time, but the reality is, if you gave it to them on time, it still wouldn’t meet their expectations.
The real problem is quality, and the solution is to use a process that is optimized for finding the best solutions through rapid iteration and tight feedback loops in conjunction with a more targeted approach to customer segmentation.
In the end, your organization can have both high quality and speed, but you have to be willing to make one simple change: Tell only the right people at the right times.