Time-To-Market

<< Previous - Introduction | Table of Contents | Next >> - ROI


Time-To-Market (TTM), or Speed-To-Market, relates to how quickly value can be delivered to a customer (where value, typically represents a consumable service, or product feature).

TTM is important for the following reasons:

Let’s review them.

MODERN CUSTOMER EXPECTATIONS

Only a decade ago, many projects were still being built using the Waterfall Methodology. In this model, work is undertaken over many months (or years), before finally being delivered to the paying customer. This approach has many problems, and is the precursor to the Agile/Lean/DevOps methodologies/practices.

Waterfall’s main problem is its long incubation lifecycle, inevitably leading to delayed delivery. Often, what’s delivered (a) isn’t what’s needed (or asked for), and/or (b) has lost some/all of its potential value/benefits. Generally, the longer it takes to deliver, the less worth it has.

ASSET DEPRECIATION

Everything deteriorates over time (it’s known as entropy). Vehicles do, people do, software does, even the heavenly bodies. It’s an inevitability. Thus, any software that rests for an unconventionally long time (aka Waterfall) is depreciating.

NOTE — THE INTERNET & TTM

The internet has been both a blessing and a curse. It’s a great business enabler, allowing information, ideas, and services to be widely shared (even internationally), but it’s also created more Ravenous Consumption. It’s forced change, at a great pace, upon traditionally conservative businesses, who must learn to quickly evolve, or die. The scale of the problem faced by the established order becomes clear when you consider the speed at which startups can outmanoeuvre those established businesses. These startups continue to eat into the profits of the established order. If I was to wager what most of the established order’s biggest fears are, it would be their inability to be nimble in the face of growing adversity.

Many businesses already beat the Continuous Delivery (CD) drum, and take great advantage from it. Look to many of the technology “unicorns” (e.g. Amazon, Netflix, and Spotify) for instance. They all exhibit a strong desire (and ability) to continually improve, a key ingredient being fast delivery.

NOTE — 11.7 SECONDS

Some time ago, a blog was posted indicating Amazon delivered change to production about every 11.7 seconds. Netflix deploy thousands of times per day. 1 2

COMPETITION

If your offering is commonplace (i.e. it offers no Unique Selling Proposition (USP)), and your competition can deliver value faster, and more regularly than you, then why would potential customers approach you? Everyone else (including prospective customers) is also engaged in this Ravenous Consumption lifecycle, and must also rapidly deliver value to their customers. Therefore, it’s natural for customers to build relationships with other like-minded nimble businesses, who have already streamlined their delivery practices.

NOTE — THE CONTINUOUS DELIVERY EDGE

Delivering quickly and regularly can give you a Competitive Advantage, ensure the right thing is worked on (important for TTM and ROI), promote Continuous Experimentation, and thus improve throughput and profitability.

LEARNING

TTM also provides a useful way to measure success (or the lack of it), gain learning, and if necessary, readjust. The sooner a feature is delivered, the sooner we can gather feedback on it (often termed Business Metrics). This feedback may be positive (e.g. “the customers like the feature and want more”), or negative (e.g. “the customers hated it”), but it’s all useful to make better business decisions.

NOTE — 80% OF IT PROJECTS FAIL?

I read that 80% of IT projects fail. Now, whilst we should entertain this statistic cautiously (e.g. what do we quantify as a “failure”?), it does suggest we should place more emphasis on understanding it, and to do this, it’s vital to gather quick and regular feedback.

LOWERING RISK

Regular deliveries also mitigates risk in two ways:

  1. By measuring a feature’s appeal, we can promptly decide whether to proceed, or ditch, improving ROI (later), and enabling us to shift focus to alternative features of greater value.
  2. Small, regular product releases are less fraught with failure than large (monolithic) monthly/quarterly releases containing many changes, better protecting Brand Reputation.

NOTE — BIAS AND INAPPROPRIATE ATTACHMENT

TTM can also mitigate Bias or Inappropriate Attachment.

Inappropriate Attachment is the concept where people become overly attached (and therefore biased) towards a project that (now) has little value/mileage. It’s a state of mind, typically caused by the significant investment of money and/or time, that makes people want to see it through to the end, even when money spent on it is being flushed away.

TTM reduces (not removes) this bias by making everything lean, from development to delivery, so less attachment.

CASH FLOW

Cash flow is a measurement of the difference between the amount of money the business brings in, and the costs of running the business (e.g. employee wages, rent, assets, electricity). Or, the amount of cash that is generated through its operations (not sales). It’s also one of the simplest ways to understand a business' wellbeing.

TTM is a useful way to understand a snapshot of a business’ cash-flow. Efficient flows indicate that work items are only in the manufacturing system ephemerally; thus indicating that some return is rapidly achieved.

NOTE — TTM & CASH FLOW

Inventory are the items in a production system, awaiting delivery. The more inventory, the longer each item sits in the system (awaiting delivery), the less cashflow a company has, increasing shareholder and investor nervousness.

Thus, TTM is incredibly important to the ongoing health of an organisation.

TECHNOLOGY’S SOLUTIONS TO TTM

The software industry has attempted to resolve our modern TTM expectations using (to name a few) the following techniques:

I’ll discuss these techniques in later sections of the book.

TECHNICAL QUALITIES AFFECTED

The figure below shows some of the technical qualities affected by (or affecting) TTM.

TTM Technical Qualities

They are:

RELEASABILITY

Releasability (the ability to regularly and easily release value to a customer) is extremely important for TTM. A laborious release cycle (e.g. quarterly) hinders learning, and shifts focus away from the real tasks (building software). Many of the technical “unicorns” have invested heavily on getting this right, using practices such as Continuous Delivery.

PRODUCTIVITY

Closely related to Releasability and Maintainability, Productivity enables us to engage in efficient working practices; e.g. using modern technologies and tooling, efficient, Just-In-Time (JIT) Communication protocols, and software methodologies. All lead to improved TTM.

FLEXIBILITY & EXTENSIBILITY

A system that is highly flexible and/or flexible (in appropriate areas) promotes TTM, because (a) any change or addition has minimal impact (e.g. limited regression testing), and thus, (b) can be delivered (relatively) quickly. This also benefits Sellability.

TESTABILITY

Testability relates to the ease with which software can be tested for accuracy. Whilst it may seem that Testability hinders TTM (why waste time writing tests when you can solely deliver executable code?), that’s only part of the story. Whilst true that Testability may sometimes hinder initial TTM, it is quickly recouped with every subsequent change required to that software (40–80% of work is undertaken in maintenance mode).

A key benefit of Testable software is that it tends to display high Test Coverage, promoting change (Safety Net), innovation, and improving medium-to-long term TTM.

SECURITY

Imagine you identify a gap in the market, leverage it by building a new system, successfully market it at all of your industry’s major conferences, and successfully sell it to a range of interested parties. Great, eh!

The problem is, Security hasn’t been considered from the start, and the solution is inherently insecure. That rush to meet TTM has actually hindered your longer-term TTM – the system needs redesigned and rebuild in several key areas ( Rework, from The Seven Wastes). You’re sales evaporate with each additional month required to rectify this issue.

Yet, to counter my own argument, much of security is about risk management, and you shouldn’t burn cash building in unnecessary controls ( Overprocessing).

SCALABILITY

It’s a little bit more difficult to imagine Scalability affecting TTM, so let me present you with an example.

I once worked with a partner to deliver downstream services for a new system. The partner delivered the desired features, but delivering the Scalability and Reliability qualities was contentious, lead to heated conversations, contractual renegotiations, and significant rework.

Two things had occurred:

  1. Too much focus was placed on initial TTM, to deliver feature-rich solutions, yet neglecting the non-functional expectations (e.g. Scalability) that can dissolve partnerships (Functional Myopicism).
  2. There had been insufficient expert involvement, or agreement, on what was acceptable.

MANAGEABILITY

Manageability (how easy it is to manage a system across environments) may also affect TTM. Environments that are slow, difficult to provision, or that are high maintenance, hamper change (and thus TTM). Having confidence in the applications you build is pretty meaningless if the underlying foundations they are built upon (e.g. infrastructure services) are unreliable, or difficult to manage (it hampers change and TTM).

REUSE

What’s the quickest way to deliver value to the market? Deliver what you already have; i.e. Reuse. If software is built with reuse in mind, it’s possible to apply the same solution on another problem. And, being a Known Quantity, delivery is much quicker.

MAINTAINABILITY

There’s two aspects of TTM to consider here:

  1. Immediate.
  2. Medium-to-Long term.

Writing poor quality code may suit immediate TTM needs (e.g. deliver something for an important show next week), but it won’t likely satisfy medium-to-long term TTM aspirations. Remember, if 40–80% of effort is spent in maintenance mode, we should ensure code is of good quality, to promote change.

NOTE — EXAMPLE

I once worked at an organisation who outsourced part of the development for a new product to an external team (success with these teams tends to be when you treat them as an extension, and manage them as you would an internal team). Unfortunately, they were left to their own devices for too long and had little foundations to build from (so attempted to build their own).

What was delivered was clearly below par (e.g. poor error handling and cohesiveness, lots of repetition, lack of consistency/uniformity), causing frustrations on both sides, reducing Stakeholder Confidence, and placing the entire partnership at risk.

Our internal teams spent about one week of refactoring time per microservice to introduce appropriate foundations to enable future changes to be more efficiently delivered. Sometimes you have to regress, in order to progress ( Regress to Progress).

PORTABILITY

I’ve been in several customer negotiations where Portability (the ability to easily “port” a solution to another vendor) was important. Solutions that make heavy use of proprietary technologies limit (or make impractical) the ability to port, thus affecting TTM under those conditions.

Conversely, solutions that are entirely agnostic can’t make use of potentially important technologies/services, and may introduce unnecessary complexity, and thus negatively impact TTM.

UNIFORMITY

If all solutions look and behave (operationally, rather than functionally) the same, there’s very little Surprise in its construction, deployment, and operation; i.e. problems/failures tend to have been experienced before and can be easily rectified). This is a Known Quantity, which is a proponent to TTM.

INTEGRABILITY

Integrability – the ability to easily integrate services together – may affect TTM/ROI in two ways:

  1. The integrator effort is significantly larger or more complex (thus longer) than anticipated, possibly jeopardising delivery dates.
  2. (Due to above) The integrator may place undue (and unexpected) strain upon your business to support them. This shifts (potentially expensive, or bottleneck) resources away from other important work items, affecting those delivery dates (this affects both TTM and ROI). The ROI costs are mainly due to your business soaking up the support costs to successfully integrate customers onto the platform.

NOTE — INTEGRABILITY

A major part of a successful integration depends heavily upon the integration’s quality. In the case of APIs, consumers typically desire modern/common API and data transfer technologies (currently REST & JSON), which are well-documented and easily accessible. Additionally, APIs should be consistent, consumer-driven, and cohesive.

CHAPTER SUMMARY

The key points of TTM are: