DevOps in a nutshell

Vive la révolution

Chris Lennon
6 min readJul 30, 2020
image Riskiyan W

Movements are generally born out of frustration. A brief glance though the history books tells us this: the Reformation was born out of dissatisfaction with the dominant religion, the French Revolution born out of anger at the practices of the ruling elite. The DevOps revolution has fortunately not involved loss of life, but its impact on those of us in IT has been significant and will only increase with time.

The traditional development life-cycle was linear — software was developed and then passed (or “thrown over the fence” in some cases) to operations to run. An invisible wall stood between software developers and software operations, a wall erected with good intentions including the need for security and stability — but a barrier that made life frustrating for both sides. With little understanding of the world of operations, developers would write code that — to use the well-known IT joke — “works on my machine”, however this code was found wanting when deployed to the vastly more complex real world of operations. By the same token operations were often seen as a bureaucratic impediment to developers being able to get value into the hands of the end customer.

So in the simplest sense DevOps is a coming together of the worlds of Development and Operations. Hence: DevOps


Compared to movements like Lean and Agile, DevOps is the new kid on the block. The term ‘DevOps’ was first coined by Patrick Debois and Andrew Shafer in 2008 . DevOps has built upon a strong foundation laid by the Lean and Agile movements and indeed many of the key moments in DevOps history have occurred at Agile conferences.

The Three Ways of DevOps

The Three Ways of DevOps, a concept first coined by Gene Kim (author of The Phoenix Project and The Unicorn Project, more on these later) in a 2012 blog post describes three ‘ways’ that, if followed, result in a greater level of collaboration between development and operations. From the blog post:

The ‘first way’ of DevOps— emphasizes the performance of the system as a whole
the ‘second way’ of DevOps: shorten and amplify feedback loops
the ‘third way’ of DevOps promotes taking risks and learning from failure

These “three ways” were given life in Gene Kim’s work ‘The Phoenix Project”. This work of fiction describes itself as ‘a novel about IT, DevOps and helping your business win’.

The Phoenix Project

The story follows Bill Palmer, a middle management IT professional who finds himself unexpectedly promoted to VP of IT Operations and in charge, from an operations point of view, of a highly visible and critical project — the phoenix project. Guided by the unconventional yet very wise Eric Reid, Bill takes the project from zero to hero and on the way learns valuable lessons from the world of DevOps. For example, Bill learns that there are four types of work in IT: Business Project work, IT project work, operational change and unplanned work.

Since the original blog, more comprehensive ways of visualizing the flow of value from development, to ops, and back again have been developed. You will often see eight phases drawn as an infinity loop:

image credit: JakobTheDev

The Five Ideals

Gene Kim’s latest work The Unicorn Project is somewhat of a sequel to The Phoenix Project — looking at the project that gave name to the first book through a different lens. The Unicorn Project tells the story of Maxine, a gifted technician sent to work in the distressed ‘Phoenix Project’ development hub. She joins with Kurt to form a ‘rebellion’ who work tirelessly to turn around a dire company situation and ultimately triumph against the forces of bureaucracy and mediocrity

Along the way the sage, Eric imparts 5 ideals to her and her band of DevOps rebels.

  • The First Ideal: Locality and Simplicity.
  • The Second Ideal: Focus, Flow, and Joy
  • The Third Ideal: Improvement of Daily Work
  • The Fourth Ideal: Psychological Safety
  • The Fifth Ideal: Customer Focus

Technical Practices

A large part of the DevOps culture is a focus on technical practices that enable and accelerate this flow of value and feedback between development and production operations. The poster child for DevOps technical practices is Continuous Delivery, the ability to deploy, to production a continuous stream of potentially releasable functionality.

The range of technical practices and tools that surround DevOps is vast, as the below illustration shows:

However seeing DevOps as purely a set of technical skills and tools would be a mistake. Yes DevOps has an unmistakable geek flavor, but DevOps speaks to the business on a deeper level.

The Inverse Conway Manoeuvre

In 1967 computer programmer Melvin Conway introduced an idea that has since become known as ‘Conway’s Law’:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

— Melvin E. Conway

In other words, the software architecture will ultimately reflect the company structure. An ‘inverse Conway manoeuvre’ then both leverages this discovery and flips it on its head. You structure the company to align with the technical architecture you want to achieve.

Team Topologies

image credit

The latest thought leadership to come from the rich soil of DevOps comes with the recent release of Matthew Skelton and Manuel Pais’ ‘Team Topologies’, which leverages and builds on the Inverse Conway principle. To achieve the technical and operational design excellence that companies today strive for only four fundamental types of teams are needed within a software organization:

  • A stream aligned team. The most common team type, this team type focuses on an end business outcome such as an area of a software product. This is a self organizing and self-sufficient team.
  • An enabling team. An enabling team exists to empower other teams. This team doesn’t as a rule do the work, rather they teach and train other teams how to work effectively.
  • Complicated subsystem team. This team type will be relatively rare, and wraps around a specialized and complex area, for example a Virtual Reality interface.
  • Platform team. Platform teams exist to give stream aligned teams leverage, literally a platform, to enable and accelerate the flow of value from planning to coding to operations.

With these four fundamental team types, or ‘topologies’ defined the authors look at how teams interact, defining three primary team interaction modes. What these are I’ll leave up you, the reader to explore — Team Topologies has some powerful concepts and is well worth a read.

The future

Make no mistake, despite or maybe because of, its quiet, agreeable and somewhat geeky demeanor, DevOps has the heart of a revolutionary. To which I can only say:

Vive la révolution!



Chris Lennon

Agile coach. Ways of Working researcher. I live in beautiful New Zealand and work for Spark. I am also the founder of a start up — Views are my own.