DevOps and the Four Ways – communication, collaboration, innovation & merciless refactoring

I have been working in the IT industry for over 30 years and have seen a lot of changes, some for the better. Management and technological fads roll through the industry like waves, leaving almost as soon as they arrive. Only a few, like object-oriented programming and the agile movement, have any longevity.

When I stumbled across “The Phoenix Project” a few years ago (the book by Gene Kim, George Spafford and Kevin Behr, not to be confused with the 2015 film of the same name) it sat on my virtual bookshelf for some time, in the growing pile of “probably another fad”. I figured I would stop hearing about DevOps soon enough.

But DevOps didn’t go away and finally, one evening, I started reading. I couldn’t put it down. 

This entertainingly light read contained gems of wisdom which took my breath away. 

Suddenly my Engineering studies, with its TQM and focus on reducing waste, plus my experience working at Toyota in Melbourne back in the 70s, and my many years in IT development and operations, all clicked together. DevOps wasn’t just about (re)combining Development and Operations, but rather it was a philosophy for how to work more effectively across the end-to-end value stream. 

In a recent post, I described DevOps as being “a philosophy or culture about collaboration, communication and innovation. DevOps encourages looking at the bigger picture and understanding the impacts of local decisions on the whole system. It also encourages seeking and responding to feedback and experimentation as a way to learn and develop.”

In this article I want to talk more about the values or principles which underly DevOps. 

The Phoenix Project introduces the Three Ways of DevOps: Flow, Feedback and Continual Experimentation and Learning. More recently, Peter Merel (XSCALE Alliance) has suggested inclusion of a “fourth way”, Merciless Refactoring.

Just as with the agile manifesto, by understanding these principles and adjusting our behaviors in line with them, we can create better outcomes for the people, teams and organizations we work with and for.

Full credit is given to Gene Kim, Tim Hunterand Peter Merel, for their respective contributions to this topic, each of whom have inspired me.

Before expanding on the Four Ways, it’s important that we understand clearly what the Dev and Ops parts of DevOps refer to. These are often interpreted somewhat literally to mean the people who do software development (Dev) and the people who support the day-to-day operations (Ops). However, this is an oversimplification which only tells us part of the story.

Development (Dev) are the representatives of that part of the organization which is responsible for creating new or enhanced products and services, the “business”. This includes software development and extends to any other aspects of change which are needed to deliver value to customers.

Operations (Ops) are the representatives, within the organization, of the users of the products and services, the “customers”. The operations teams are responsible for ensuring products and services are delivered reliably and on time and they usually deal with problems and defects which impact the customer’s experience.

So, in a way we could call it “Bus – Cust” or “BusDevOpsCust”, although DevOps does roll off the tongue more easily ;) 

Part of the reason “DevOps” is so successful is because there is often a natural friction between these two parts of an organization. “Dev” wants to change things by adding new products and features, while “Ops” wants to maximize the reliability and minimize defects.

With these definitions in mind, let’s take a look at the Four Ways …

THE FIRST WAY: FLOW

The Way of Flow focusses on understanding and improving the movement of business value through the system, from business idea through to finished product delivered to the customers.

By looking at our organization in terms of “flow” of value, and understanding the end-to-end steps and activities involved, we become aware of inefficiencies and bottlenecks which help us to:

• Increase the value flow by removing bottlenecks and constraints
• Identify where work is piling up (unused work in progress) or where teams have excess capacity and are waiting for more work. With this knowledge we can make changes to improve efficiency and ensure teams get what the need, when they need it.
• Detect and resolve defects earlier so that they don’t get moved on to other teams or, worse, to customers
• Ensure the “Ops” teams are involved in the development process and can more effectively prepare for the planned changes
• Deliver new and improved products to customers faster, with less defects

 THE SECOND WAY: FEEDBACK

The Way of Feedback focusses on communication and, in particular, the flow of information from the Operations teams about the results of the work being delivered by Dev.

By creating visibility on the outcomes of their work, the Development teams can better understand the impacts of their decisions and improve practices in response.

This was a core tenant of Beck’s “eXtreme Programming” and is encapsulated in the “AGILE Manifesto”, the concept that consistent frequent and rapid feedback loops drive process improvement. Hence the 4thPrinciple of the manifesto is “Close, daily cooperation between business people and developers”.

This doesn’t necessarily mean we have to combine the Dev and Ops teams! I have had clients tell me they “can’t do” DevOps, because they need to keep Dev and Ops separate, however the idea that DevOps is simply about combining these teams has been driven by consultants using the term as a marketing tool without understanding what it actually means.

What it does mean, is that we want regular and consistent collaboration and communication.

Involve the Ops team in design sessions and in product review sessions. Have members of the Dev teams take turns in helping with incidents. Join each other team’s stand-up meetings.

Bringing Dev and Ops closer together helps to:

• Foster an environment of trust and understanding.
• Share knowledge
• Increase collaboration, which in turn helps to improve Flow
• Identify and fix defects earlier and understand the reasons why things have gone wrong
• Improve practices to avoid defects re-occurring
• Reduce and avoid unplanned work (which will otherwise sap our teams time and energy)
• Deliver higher quality, faster

 THE THIRD WAY: CONTINUAL EXPERIMENTATION AND LEARNING

The Way of Continual Experimentation and Learning follows from and builds on the previous two. 

With the mutual trust we have developed between Dev and Ops, we can safely experiment with new ideas knowing that we have the ability to quickly identify and fix problems if they occur.

Experimentation can lead to failure, and each failure teaches us something. It can also lead to great successes, which we wouldn’t have been able to achieve without taking risks.

Our feedback loops and collaboration enable us to plan for change and respond quickly to issues.

Continual Experimentation and Learning leads to:

• We make mistakes, and learn from them
• We get better at identifying and fixing defects
• The resilience of our products and services increases
• Unplanned faults can be detected earlier and fixed faster
• More innovation and breakthroughs
• Growth and learning
• Constant stress testing of our system(s) helps us decrease cycle times and improve flow

THE FOURTH WAY: MERCILESS REFACTORING

TheWay of Merciless Refactoring means that we take time to simplify and automate solutions: simple, automated systems cost less to maintain than big, manual ones, and take less work to create more useful outcomes.

We use the term merciless refactoring borrowed from XP (eXtreme Programming) where it meant a continuous and rigorous team discipline explicitly supported by quality automation and collective ownership.

In DevOps terms, Merciless Refactoring means Dev proactively and systematically simplifying all the value, work and learning flows: improving their design without changing their function. 

The fourth way is what Peter Merel calls "the Zeroth way", because it's the base upon which the other Ways are founded; As the key tenet of XP it's actually the origin of DevOps, and it has the functional meaning of extending XP's Merciless Refactoring to operation of the whole organisation.

That doesn't just apply to the design of code, but of data, configuration, hardware, service interfaces, and organizational communications and commercial channels.

Development prioritises work on Operational metrics that assure Customer satisfaction and Operations prioritises work on costs of Development to accelerate Business throughput.

The Fourth Way is the driver of DevOps' traditional, necessary and continuous investment in automation of the end-to-end workflow. This is why so much attention is paid to topics such as continuous integration, continuous testing, continuous deployment, etc.

When we focus on Merciless Refactoring we achieve:

• Minimising the organization's cost of change
• Reversing the growth of complexity which otherwise creates exponential delays and costs and ultimately stifles delivery of value and innovation
• Automation to simplify the process of simplification
• Reduction in technical-debt

SUMMARY

DevOps is a simple yet powerful driver for cultural change which focusses on collaboration, communication and innovation. 

DevOps encourages looking at the bigger picture and understanding the impacts of local decisions on the whole system. It also encourages seeking and responding to feedback and experimentation as a way to learn and develop.

I would encourage you to take up the challenge to learn more about DevOps and how it can improve the way you and your team(s) work together. There are many resources on the topic, and the “Phoenix Project” is an excellent (and entertaining) primer.

I hope this short article helps you to better understand what DevOps can bring to your team and organization. I wish you every success in your continuing agile and DevOps journey.

Stay Agile :)

Christopher Young.

#devops #3ways #4ways #descaling #finaplana