Continuous Delivery Beyond IT: Small Deliveries in the Business

Continuous delivery beyond IT means releasing business change in small, finished units instead of bundling it into large packages with a single deadline. The principle comes from software engineering, yet it applies wherever a business function changes prices, processes, offers or campaigns. Small deliveries shorten the wait for the first effect, reduce the risk of each step and produce earlier evidence on whether a change works in the market.

This article explains what continuous delivery means at its core, works through an example that shows why small deliveries take effect sooner, and sets out a four-step plan that takes a business function from annual planning to continuous release.

What does continuous delivery mean outside software development?

Continuous delivery means that every change is always in a releasable state and goes live in small steps. Jez Humble and David Farley coined the term in their book of the same name in 2010. Their definition describes the ability to get changes of all types into production safely, quickly and sustainably. The words “of all types” make the transfer possible: they cover configuration changes and experiments as well as new features, and in a business setting new price tiers, sales scripts, ordering routes or advertising creatives.

The roots go back further than the software industry. The Toyota Production System works with one-piece flow, in which each part moves to the next station immediately instead of waiting in a lot. In “The Principles of Product Development Flow” (2009), Donald Reinertsen showed why small batch sizes shorten cycle time and dampen variability. They also speed up feedback. Continuous delivery applies this logic to change, and it works in any function whose work consists of change.

Nicole Forsgren, Jez Humble and Gene Kim described four measures of delivery performance in “Accelerate” (2018): lead time for a change, deployment frequency, time to restore service after a failure and the share of changes that fail. Translated for a business function, the questions read: How long does it take from decision to effect at the customer? How often do we change something? How quickly do we reverse a misjudgement? How often must we rework a release? These four questions form a measurement system for any function, without a line of code.

Why do small deliveries take effect faster and carry less risk?

Small deliveries are faster because the time to effect grows with the amount of work in progress. Little's law (John Little, 1961) describes the relationship: average cycle time equals the number of items in progress divided by throughput per unit of time. A worked example shows the effect.

The figures are chosen to show the logic of the calculation. What matters is the mechanism: in the annual package every change sits finished for six months on average before it takes effect, and the market reveals only after twelve months which of the 24 adjustments was right. With small deliveries the first effect is visible after a few weeks, and every finding feeds into the next adjustment. The wait between completion and effect is lost time in which the company neither earns nor learns. The article on time-to-market describes how to trace such waiting time in detail.

Risk follows the same pattern. A large delivery bundles many assumptions, and when the result disappoints, nobody knows which assumption was wrong. A small delivery tests one assumption, and the damage from a misjudgement stays limited. For the same reason the effort for coordination and approval falls with batch size, because a change with limited downside needs fewer committees than an annual programme.

What does a small delivery look like in sales, procurement or marketing?

A small delivery in a business function is a closed change that a customer, a supplier or a colleague notices and that shows an effect on its own. Four examples make the cut tangible.

In sales, a new quotation process arrives in steps: first the cover sheet for one customer group, then the approval rule for discounts up to a threshold, then the follow-up routine after five days. In procurement, a new supplier model starts with one commodity group in one region, and the remaining contracts run on for the time being. In marketing, a campaign goes out with one segment and one creative before the budget is released for all markets. In customer service, a new reply template for the most frequent type of enquiry goes live before the whole knowledge base is overhauled.

The same test applies in all four cases. A delivery is cut correctly when it answers three questions with yes. Is it finished within two weeks at most? Does it work on its own, even if every other initiative stands still? Can it be reversed without harm to customers or staff? If one answer is no, the delivery is split further until all three hold. The article on the definition of done shows how to define “done” so that it is done from the customer's point of view.

Which prerequisites does a business function need for continuous release?

Four prerequisites decide whether small deliveries work in daily practice. They mirror the building blocks of a deployment pipeline in software engineering.

1. Standardised routes: every type of change has a fixed process with defined approval. A price update always runs through the same steps and the same roles. Exceptions stay exceptions.
2. Automated routine: recurring steps such as data maintenance or reporting run without manual work, so the tenth delivery costs no more effort than the first.
3. Fast feedback: for each delivery it is settled in advance which metric should move and when it will be read. Without this measurement a small delivery is only a small step without insight.
4. A way back: every change comes with an answer to the question of how it is reversed and who decides.

How does a business function introduce continuous delivery in four steps?

The shift from annual planning to continuous release takes four steps, and each step leaves a usable state behind.

The first step makes the current position visible. The function lists all initiatives in progress, sorts them by age and measures the time between decision and effect. The list usually shows that many changes wait longer than they are worked on. The article on waiting time in processes provides a method for this.

The second step limits work in progress. A fixed ceiling on the number of initiatives forces completion before anything new begins. How this works is explained in the article on limiting work in progress.

The third step splits the largest initiatives into deliveries of two weeks at most, using the checklist above. Each delivery gets an owner, a metric and a way back.

The fourth step sets a fixed rhythm: a short weekly session that decides what ships, and a monthly look at the four delivery measures. From this rhythm emerges what Humble and Farley describe as the core: releasing becomes routine and stops being an event.

Where does continuous delivery reach its limits in the business?

Continuous delivery reaches its limits where a change only makes sense as a whole or where no way back exists. The relocation of a plant, the merger of two entities or a printed product line cannot be delivered in weekly portions. A different cut applies there: preparation is split into small deliveries (data cleansing, a pilot site, a rehearsal) while the event itself remains a fixed date. Deliveries that would confuse customers, such as weekly changing price lists, should also be bundled. Batch size follows customer value and the way back, and the planning calendar has no say in it.

Continuous delivery in the business with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the service area of delivery management he takes the role of delivery manager, project manager or product owner and aligns organisations so that deliveries reach the business in a short cycle.

The approach follows the Niehues Delivery Model with its three phases. For continuous delivery three of its test questions matter most: Which business outcome should change measurably? Which roles and decision paths does operations need? Which metric shows after 90 days that the solution has landed? The entry point is a free initial consultation of 30 minutes, which you can arrange via the contact page.