The Need For Speed In Digital Transformation

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

2M+ Devs and QAs rely on TestMu AI

Deliver immersive digital experiences with Next-Generation Mobile Apps and Cross Browser Testing Cloud

Sign up with googleSign up with Email