The Need For Speed In Digital Transformation

Launched in 1985, Blockbuster video had twelve years of unrivaled growth, checked only by a technical innovation – Netflix offering video disks in the mail. That service saw a little less time, ten years of growth before it decided to cannibalize its own business to offer video on demand. Competition for paid video on demand only took three years to get started, with the creation of Hulu+. Today, the entertainment marketplace is littered with streaming services, including Disney, Paramount, Amazon Prime, and NBC.

1985 – Blockbuster video launches
1995 – First Mass-Market Windows operating systems (Windows 95)
First browser to ship with the operating system (Internet Explorer)
1997 – Netflix launches, shipping DVDs in the mail
2007 – Netflix offers video on demand
2008 – Roku (stick) launches
2010 – Blockbuster declares bankruptcy, Hulu launches Hulu+
2014 – Roku launches Smart TV product

We could take this chart and work backward. Cable television had a few decades; local television had more time than that. Radio had still more, and newspapers had centuries. This observation isn’t just me; Tom Peters and Robert Waterman were talking about it in 1982 when they wrote In Search of Excellence.

We see the same compression of timeline in software: The Waterfall model ruled from 1970 until the creation of Scrum and XP in 1995. David Anderson’s paper From best to worst in 9 months ushered in the era of Kanban in 2005, while Humble and Farley published their book Continuous Delivery just five years later. Cloud-native and mobile applications came on the scene just after.

The window between when an innovation is disruptive and profitable, and when it is old news, is shrinking. One term for this is the cost of delay.

Cost of Delay

When software teams talk about the value of their work, they often talk about “points” or “velocity”, perhaps “stories per week.” None of this means anything to a decision-maker with profit and loss responsibility. What does? Cost of delay.

Imagine your team had the feature right now and could sell it today. How much money would you make this week, this month, or this quarter? That is the cost of delay.

It’s easy to think of the cost of delay as a single number – “we could make a million net profit per month if we could sell the product today.” In reality, it is more likely a window of opportunity, with sales increasing to a peak and then heading back down again. The team at Black Swan Farming suggests that the cost of delay has three advantages:

• Clear Priorities. Using the cost of delay divided by duration to build a feature provides a single number to compare competing priorities against.
• Better Tradeoff Decisions. Looking at cost of delay can help a team understand the impact of multitasking, buffers, and delays inside the software delivery system.
• Changes the conversation. Without understanding the cost of delay, staffing decisions tend to be made about pre-determined schedules and deadlines, which might or might not be realistic.

Combining the cost of delay with our knowledge of the speed of transformation, we realize that the window to capture profit is shrinking. Netflix spent ten years developing their online streaming service but was only without competition for four. At the same time, solution delivery is moving from physical to digital. Show tickets are on a phone, cable television is moving to digital on-demand, even Amazon, the world’s largest bookseller, decided to risk its own book business by delivering books electronically with the kindle. They had to; if they didn’t, someone else would.

Joseph Shumpeter, a political-economist of the Austrian School, called this creative destruction. Amazon created jobs, but it also destroyed the local bookseller. The personal computer made the mainframe obsolete, the laptop supplanted the desktop, and today the mobile phone is eating into laptop sales.

With the window for delay shrinking and competitive pressure mounting, time to market for digital transformation becomes more important than ever before.

Sidebar: The C3 Story

The first major Extreme Programming, or “XP” project was run at an American auto manufacturer in the mid to late 1990s. At the time the company was known for big waterfall projects that might take three years. The company might hire an outsourced business firm to conduct an analysis, over the course of the year, then hire a design firm to lay out the high-level design and software architecture, over another year. Finally, the programmers would implement. At each step, the receivers might find the work unacceptable and start over. By year two or three, there might be a new CIO, who might cancel the project. Projects canceled in design, or even mid-code, would have no tangible value to the company.

When XP was born, the programmers had a new idea, structuring the work in “iterations” of two weeks, and going to production every three iterations. The programmers were, essentially, timing a race, with the goal of getting to production before the project could be canceled. The initial release of the project, which was the Consolidation Compensation project, printed paychecks only for one category of employee – hourly interns at headquarters that had no deductions.
C3 ended over twenty years ago.

Moving Forward

Today, combining build, test, and release to ship quickly in hours, not days, is no longer a competitive advantage; it is the way forward.

Here’s four ways to do it.

First, analyze your existing delivery cycle. What elements take the longest? How can they be sped up, automated or eliminated? If you can find the bottleneck and accelerate it, the entire project will go faster.

Second, analyze your risks. Software process seems to grow like a weed. A problem in one place that happens one time leads to a double-check process that slows down every change that rolls out. Look for double checks that are not adding value; remove them. Consider, for example, the difference between regression testing the entire site and just checking what changed. Of course, that will be risky, so we need step three.

Third, build failsafes. These can be tools to catch problems early, or tools to rollback quickly in the event of a breaking change. That can include monitoring errors and user behavior when a change rolls out.

Four, decouple dependencies. Make it possible to change just one thing, with contracts around behavior, and deploy just that one change. That could lead to error. Then again, that is what we have the failsafes for.

There’s a simple list of how to move faster; what are you doing next?

Author- Matt Heusser