Releasability

Table of Contents


RELEASABILITY

TTM ROI Sellability Agility Reputation

The ability to efficiently, repeatedly, and reliably deliver value to the customer.

The act of delivering value (the output of your business) to customers should be foremost in the thoughts of most organisations. Again and again though, I see it demoted to a second-class status. Yet without such a quality, it matters little how spectacular your features are if there's no effective way to get them quickly and reliably into your customers hands.

MISSED DELIVERIES

Missing an expected delivery date is a very quick (and effective) way to upset a customer - promising to deliver something, and then failing to do so.

The more obvious cases include: the output isn't ready (or sufficiently stable), and (of interest to us here) it's ready, but it suffers from poor Releasability.

Businesses with slow delivery pipelines typically have many features (ideas, and money) tied up in Manufacturing Purgatory. This has ROI implications - you're getting zero return on those outputs. Additionally, waste also occurs through the lack of fast feedback (Fast Feedback), forcing us to invest more time and money in some features than they deserve (Features Success is a Form of Betting). Good releasability reduces Manufacturing Purgatory, hastens feedback, and typically leads to happier customers.

Unfortunately, delivery in many (more established) organisations is still notorious for its high-risk, difficulty, and effort. This is largely because: (a) long delivery times were once an acceptable way to deliver to customers (How We Got Here), (b) Monolithic architectures were once the norm, and (c) there were few alternative delivery approaches. Delivery was painful, so it was avoided. Consequently this led to more pain.

REPEATEDLY

Note that the use of the word “repeatedly” as part of the Releasability definition (top of section) is important. Releasability is not simply a measure of how quickly you can deliver a single (initial) change, but how you repeatedly deliver value to customers day after week after year. Delivering it fast, once, doesn't count.

Normalising delivery then, by increasing their regularity, and including them as part of the daily job (our Definition of Done), reduces its burden.

COMMON SIGNS (OF CHALLENGE)

I've indicated below some common signs of Releasability challenges.


Let's discuss them now.

MISSED CUSTOMER EXPECTATIONS

Are your customers expecting swift and regular delivery, but you're unable to do so? Then you're letting someone down. Also see Release Cadence.

“DIFFICULT” RELEASES

Ok, let's face it, many of us have suffered the odd “difficult” release. You know, those releases where it seems like anything that could go wrong, does. Typical examples include: ping-pong releases (back-and-forth between different departments over weeks), missed deadlines, late-night crunches to meet an impending deadline, misconfigured systems (e.g. due to manual intervention), and deployments that need to be diagnosed in production during the release window.

These are all examples of problems I've encountered, indicating either a technical or a cultural Releasability concern. To regularly face such problems is a poor reflection on the leadership.

METHODOLOGY

Is your Methodology suitable for the demands you and your customers place on your business?

Each methodology manages releases differently. Some batch changes and then release all at once (Waterfall), others (Scrum) release smaller amounts of change with a regular (typically fortnightly) release cadence. Some (Kanban) release as soon as the change is ready (just-in-time), and don't wait for others. You can choose to mix-and-match based on projects, but the choice should align with customer needs.

LONG RELEASE CADENCE

One of the most obvious signs of Releasability challenges is a Release Cadence far longer than desired by you or your customers.

BATCHING OF CHANGES

Batching seems a very logical approach to take. You gather all of your changes together at the end, and then deploy them as a single unit (release). Unfortunately, batching has a number of undesirable traits, including:

BATCHING TO COUNTER UNWIELDY PROCESSES

Batching may also be used (as an attempt) to counter unwieldy downstream work streams that can't (currently) function either at a high-pace, or with low-grained work items. This is a tacit agreement to accept the status quo - by satisfying the existing constraint (Theory of Constraints), rather than attempting to improve it - it isn't improving Releasability.

SILOS

The use of centralised teams may be a necessity. It may also be an organisational relic of the past that affects Releasability.

Silos tend to reduce Shared Context - important information is lost, particularly in the Waiting stage. They also tend to have many competing activities (juggling priorities, and Expediting) - i.e. your release may not get the attention that you think it deserves. This increases the likelihood of waiting.

Additionally, silos also tend to be short on diversity (in thinking and experience), which may be detrimental both to quality (problems are caught too late) and Fast Feedback.

WAITING & HAND-OFFS

Waiting (The Seven Wastes) and hand-offs - queues - to others is another sign of inefficiency. No value is being added (in fact Entropy is already at work) in the waiting state. Shared Context is also lost during this transition.

LACK OF UNIFORMITY

Every business is unique. Even the entities (departments, and teams) within them are unique. This leads to divergence, the friend of fast, but the enemy of scale.

Value Streams capture all of the actions (and effort) required for your business to release its value to its customers. Businesses lacking in Uniformity tend to have large, many-branched value streams that: add to overall delivery complexity, create more bespoke (specialist) work, and reduce capability bandwidth (there's fewer people with those skills). Overall it makes for a more convoluted, hard-to-automate process, and scalability concerns (see Throughput).

THROUGHPUT CONCERNS

Throughput (or lack of) is one of the most fundamental reasons for lack of Releasability. It matters little if your engineers can produce code rapidly (in one technology) if subsequent stages lack the resources necessary to deliver the rapid change. Consider the table below.

Branch Skill Number of people Units in a week
Red A 1 2
Blue B 5 7.5

The (one) person in the Red branch is 50% faster with skill A than the equivalent person in the Blue branch with skill B, but there's only one of them, and those skills aren't easy to come by. We can only get two units of work down that path in a week. It might cost us more (50% less efficient), but we can get almost four times the amount of work down the Blue path in that same period.

The moral of the story? Consider the impact of introducing a new skill into a business (e.g. your value stream), and your willingness to scale it up, before supporting it wholeheartedly. See Theory of Constraints.

OUT-OF-HOURS RELEASES

I don't care to think about how many hours of my life I've spent supporting out-of-hours software releases. They suggest: (a) you're releasing too much (batching change), and/or you're uncertain of its success (and preparing for a significant rollback period).

Out-of-hours releases can also be due to an overcompensation, such as when the business has experienced previous failures, so expect staff to be available even when they're not required.

They're morale-zapping endeavours that are best avoided.

MANUAL DEPLOYMENTS & PROVISIONING

Manual deployment, configuration (e.g. within that environment), or environment provisioning is another signal to watch out for. Even if the practice is relatively fast, it can create a specialism (Single Points of Failure), and is fallible (e.g. missed configuration, manual steps, out-of-order, missed upgrade). There are many tools out there to help remedy this.

MANUAL TESTING

The overuse of manual testing (in automate-able scenarios) is another sign that something could be wrong. Manual testing is slow, and prone to errors, so creates problems for Releasability [1].

SIGNIFICANT BRANCHING & MERGING ACTIVITIES

The effort of merging significant amounts of code also has a whiff about it. As does the nomination of an individual (or team) to undertake said merge activities. This suggests significant effort (i.e. complexity), and the batching of (many) changes, which carries risk (e.g. large Blast Radius).

Also, some organisations use branching to manage different client releases; i.e. each client requires bespoke features, so gets their own branch of a trunk. It's a copy of the original branch, plus the bespoke aspects needed by that client. This is highly convoluted, slow, and error prone. It's also difficult to automate.

RELEASING WHEN YOU SHOULD BE DEVELOPING

Developers are one of a (technology) business' most valuable assets. They translate ideas into working solutions that your customers pay for. Any time that they spend doing other (involved) unrelated tasks isn't conducive to your business.

That doesn't mean they shouldn't be part of the release process, only that they're given all of the tools (and training) needed to make it both swift and successful. I suppose I should also argue that the role of a release manager is in some circumstances an anti-pattern. Why wouldn't we try to simplify a release, rather than hand all of its complexity over to someone who must spend all of their time coordinating it?

OTHER VALUE-ADDING ACTIVITIES

“But… we've finished writing the code. Why can't we release it?” Because you've not engaged with all of the required teams.

Some software solutions require other activities to be completed before it can be delivered. You mustn't forget about them. For instance, is there an expectation for user/integration documentation, the distribution of a completed test plan, governance to track, or handover documentation? The point is, if it's part of your definition of done (Definition of Done), then it needs done. If it isn't then it affects your Releasability.

If these activities can't be (immediately) automated, then they need to be well-coordinated, and sufficient time and support put into them to ensure they're in place when the software lands. In many cases, these activities need not wait for the entire solution to exist.

COMPLEXITY

The complexity of the delivery process (and the codebase) can hamper Releasability.

Some businesses are shocked when they see their value activities laid bare on a Value Stream, as it suddenly dawns on them how unnecessarily complex their existing processes are.

CHARACTERISTICS & INFLUENCERS

So, what influences Releasability? Below are some of the factors.


See Releasability - Solution Mappings for a more detailed breakdown.

PILLARS AFFECTED

TTM

By ensuring that we can always release and deploy, we can be sure we're always delivering value to our customers efficiently and effectively.

ROI

Of course normalising delivery has a financial cost. It can take months (or years) to embed modern delivery practices into an organisation. So, is it worth it?

You'll see its influence on the other pillars, but let's focus on ROI here. One of the biggest challenges in product development is working on the right thing. Remember the saying of “do the right thing, over the thing right”? It means we should prioritise working on the correct things, ahead of prioritising the quality of said things. No, I'm not downplaying the role of quality. My point is that there's little point investing money (and time) into a feature that customers ignore (The Seven Wastes).

The surest way to know if customers will use a feature isn't to ask the engineering (or product) team. It's by delivering it to them, and then seeing what they do with it. Delivering something quickly - even in an unfinished state - gives us (relatively) instantaneous feedback, allowing us to more effectively adapt. This equates to an economical spend.

Swift releases also reduce the time an investment rests in Manufacturing Purgatory, allowing us to get our return back sooner.

AGILITY

The Fast Feedback we receive from high Releasability enables us to more readily adapt to change (Agility), and make good decisions, sooner.

SELLABILITY

The ability to swiftly and reliably deliver software is a valuable commodity to most customers, and thus a valuable sales tool. Conversely - since Releasability also touches on Reliability - consider a slow (or flawed) release mechanism an obstacle towards sales.

REPUTATION

I've already described how - unless countered - the speed of change carries inherent risk. The bulk of change though, is another concern.

Large (batch) releases also carry risk because: it is vast (the Blast Radius is broad), and it is delivered over a much shorter time frame (in the relative sense, you get an almost instantaneous delivery of many changes). As such, it's significantly harder to pinpoint exactly which change caused a problem, nor readily identify a root cause and resolution.

Conversely, responding quickly to customer needs is bound to have a positive effect on your Reputation.

SUMMARY

Releasability is the ability to efficiently, repeatedly, and reliably deliver value to the customer. The “repeatedly” part is important, to ensure your business achieves Sustainability.

Releasability is so important that it affects every business pillar. It's the decisive factor on what value your customers receive, and when they receive it.

Some common signs of Releasability issues include: the inability to meet customer expectations, regular “difficult” releases, a long Release Cadence, batching, manual work, a lack of Uniformity, and significant complexity.

FURTHER CONSIDERATIONS