Continuous Delivery - the meaningful catch-all term

“Continuous Delivery” a phrase first coined in context of software development in the 1^st of the 12 principles behind the Agile Manifesto from 2001:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software¹

Agile and Lean

Click to sign up to the MeetUp group 'Continuous Delivery Users' it's free!

However; in context of processes more generally, the concept of something being continuous is historically tied to the paradigm of Lean Manufacturing which at its core is founded in Kaizen (改善)² in Japanese language it means “Change for the better” and in Lean Manufacturing it’s meaning is “Continuous Improvement”. The subject of the continuous improvement is the value stream another core term in lean; Every single tiny change is rooted in the quest for optimizing the value stream to make it an unhindered flow - a continuous delivery - as opposed to an abrupt series of phases. Kaizen is credited for involving all roles in the organization - from CEO to blue collar floor workers. Kaizen is a holistic approach as opposed to a divide-and-conquer approach.

The agile movement took off in the 1990s. It’s a scholarly example of Thomas Kunh’s term Paradigm Shift³. It was a model crisis⁴ which led to a revolution; a revolt against heavy weight methods towards lightweight methods. The founding fathers of the Agile Manifesto actually considered⁵ the terms Agile, Extreme, Lightweight and Adaptive but in the end - as we know - they went with Agile.

Up until the agile paradigm shift the process of system- and software development had notoriously been comparing itself and lending it’s lingo from the field of construction; houses, bridges, skyscrapers - we still have a reminiscence in our current lingo from that pre-agile era: construction, phases, architecture, module, design. The term Lean itself originates from 1988⁶ - and derives directly from TPS; Toyota Production System but it’s part of a general and larger movement that happened in almost all manufacturing in the 1980s which also bred and put focus on well know terms such as TQM (Total Quality management), Six Sigma, Product Lines, JIT (Just In Time).

Agile was heavily inspired by lean and the successful paradigm shift that had happened in manufacturing in the previous decade. It was like the agile movement said:

What if we’re wrong in comparing software development processes with the heavyweight process adopted from the field of constructions? It feels like our process is closer related to new and lightweight process in lean manufacturing.

All the markings in red are die-hard and core lean principles which originates from the pre-agile paradigm of lean manufacturing - there's literally not a singe one of the agile principles that is not related to lean - one way or another. (Click to see the image full size)

The ‘continuous’ inflation

Two important books in software development came out in 2007 and 2010; “Continuous Integration” and “Continuous Delivery” respectively. Although the books weren’t really related much other than being published in the same book series by Addison Wesley they were seen by many as vol I+II in a potential new continuous movement - recognized by the combined abbreviations CI/CD. Suddenly we also had Continuous Deployment, Continuous Testing, Continuous Release, Continuous Learning - all this comes on top of the originally kaizen reference; Continuous Improvement.

It was an inflation of the word continuous - you could put any discipline in front of it, and then is was supposed to mean something clever and insightful.

Surely the term Continuous Delivery itself never constituted a model revolution. In hindsight there were far more important “continuous x” buzzes at play:

Google Trends on Continuous “anything” + DevOps. The search topic “CI/CD” is basically unheard of until the summer of 2016 but already in October 2017 the topic “CI/CD” becomes more searched for, than it’s ancestor “continous delivery”. And while “continuous integration” literally defines the index in this trend analysis all the way through 2016 the real champ in this chart is “DevOps” nothing comes close.

DevOps! - is that a paradigm shift then?

Click to take the 3 min survey on 'CoDe-U' and 'Continuous Delivery'

DevOps originated from 2007, to begin with DevOps was merely a spotlight on Agile Infrastructure. It was bred from the frustration that in siloed organizations it’s hard - close to impossible - to extend the lean/agile mindset beyond the development process; even the sibling process of infrastructure and operation remained heavyweight.

The term DevOps was born out of this frustration. But it didn’t really catch fire until 2013 where the concept of containers and Docker hockey stick’ed in the charts⁷ and gave an entirely new and disruptive (in the literal meaning of the word) approach to infrastructure, by making infrastructure easy and programmable accessible to developers.

Soon other siloed departments were dragged into the feast - what about security and test? They are also notoriously heavyweight processes, so why not DevSecOps? or DevTestOps? Quickly the DevOps term grew in popularity.

DevOps also suffered an inflation, like the previous continuous term did; DevOps began to encapsulates - even swallow - all the things that we’re used to credit to agile and lean; team culture, organizational culture, responsibility, feed-back loops, processes⁸, agile methodology, CI/CD, DevSecOps, BizOps, system architecture, automation, continuous delivery⁹, philosophy, team empowerment, iterative and incremental processes, continuous learning, optimized flows¹⁰. The whole shebang!

In 2021, there’s literally nothing software related that DevOps doesn’t claim to co-own. In that sense DevOps does not constitute a paradigm shift in Khun’s meaning of the phenomena. There’s no revolution. Worst case, there’s only an overwhelming large portion of Late Majority and Laggards¹¹ who are late to the DevOps party, and who now seek to make the party woke by claiming that everything we previously did still counts - thank god, then we don’t have to change - or optimize.

Recently (Oct 2021 @ GitHub Universe) Emily Freeman, Author of the book “DevOps for Dummies” announced the sunset on the term DevOps in a YouTube post¹². Her argument partly being, that it’s now such a bloated term that it can literally mean anything to anybody.

So why even bother about “Continuous Delivery”? It’s probably the smallest of all the buzzwords!

Well maybe the fact that it’s a small silent buzz gives us an indication that at least it’s not bloated - it’s one to be taken serious.

A substantial amount of the problems that lean and agile was supposed to address remain largely unsolved - especially in organizations that are victims to the Digital Transformation; The phenomena that “Software Is Eating The World”¹³. Companies who used to be nicely and cleanly defined as banks, insurance companies, shops, hardware manufacturers, music stores, … turned into software companies in less than a decade.

And most of them had absolutely no clue on what to do about it!

This was clearly not just Ops lagging behind - it was literally any department in a siloed setup of abrupt handovers entwined in red tape who claimed to duly contribute to the overall value stream, when all they really did was to stubbornly refused to change - not even small hardly noticeably continuous optimizations were allowed into the process - and in the meantime the world was being eating by software.

There’s no way these problems can be overcome unless we address the entire company or corporation.

But there’s also no way that DevOps can grow to make sense in all departments or business disciplines. Not even Scrum og agile can do that - all these terms are tainted with software semantics. HR, security, test, finance, upper management, sales, marketing, account management, share holders, board members - they will never buy it!

But if neither DevOps nor Agile - the two brightest lightsabers in the weaponry - can cut through the problem. Then what can?

To include everyone - literally - we need a less software centric lingo - a more inclusive and holistic approach.

The continuous optimization of the shared value stream, to shape it into a flow of continuous delivery can cut through it all - and bridge it. Continuous Delivery is an unbiased ideal, an objective that it makes sense to strive for, regardless of your professional background or job functions. It’s not biased towards tech or software.

It’s lean.

Let’s talk and walk “Continuous Delivery”

I would be so grateful if you would join the Continuous Delivery community - let’s form a crowd!

Click to sign up to the MeetUp group

It’s free to sign up to the Meetup Group CoDe-U; “Continuous Delivery Users”, we’re already 625+ members. We’re hosted out of Copenhagen and we have a full-day conference in Copenhagen in the making. But we will setup events and meetings wherever there’s a community.

Click to take the 3 min survey

Also; We have an ongoing survey (3 min) about the general interest and market fit of “Continuous Delivery”. We’re exploring topics, formats, engagement. It’s a google form and you can participate anonymously. We would just ❤️️ to get your feedback and reflections on Continuous Delivery_.

References