Digital Transformation with the Three Ways of DevOps

The DevOps Dojo

The three ways of DevOps comes from the Phoenix Project, a famous book in DevOps circle.

This episode covers how to use the three ways to progress in your digital transformation initiatives.

Sources:

https://www.businessinsider.com/how-changing-one-habit-quintupled-alcoas-income-2014-4?r=US&IR=T

https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations-ebook/dp/B01M9ASFQ3/ref=sr_1_1?crid=316RJMM06NH59&dchild=1&keywords=the+devops+handbook&qid=1600774333&s=books&sprefix=The+devops+h%2Cstripbooks-intl-ship%2C235&sr=1-1

Transcript:

My first introduction to the principles behind DevOps came from reading The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. In this seminal book, that blew my mind we follow Bill as he transforms Parts Unlimited through salvaging The Phoenix Project. An IT project that went so wrong, it could almost have been a project in the public sector. Through Bills journey to DevOps, we discover and experience the Three Ways of DevOps. In this episode, I cover the three ways of DevOps and how they can be applied in a Transformation. This is the DevOps Dojo #6, I am Johan Abildskov, join me in the dojo to learn.

In the DevOps world, few books have had the impact of The Phoenix Project. If you have not read it yet, it has my whole-hearted recommendation. It is tragically comic in its recognizability and frustratingly true. In it, we experience the three ways of DevOps. The three ways of DevOps are Principles of Flow, principles of feedback and principles of continuous learning. While each of these areas support each other and has some overlap, we can also use them as a vague roadmap towards DevOps capabilities.

The First Way of Flow addresses our ability to execute. The second way of Feedback concerns our ability to build quality in and notice defects early. The Third way of Continuous Learning focuses on pushing our organizations to ever higher peaks through experimentation. The first way of DevOps is called the principles of flow.

The first way of DevOps is called the principles of flow.

The foundational realization of the first way is that we need to consider the full flow from ideation until we provide value to the customer. This is also a a clash with the chronic conflict of DevOps with siloed Dev and Ops teams. It doesn't matter whether you feel like you did your part or not, as long as we the collective are not providing value to end-users. If you feel you are waiting a lot, try to pick up the adjacent skills so you can help where needed.

We also focus on not passing defects on and automating the delivery mechanisms such that we have a quick delivery pipeline.

Using Kanban boards or similar to visualize how work flows through our organization can help make the intangible work we do visible.

A small action with high leverage is WIP limits. Simply limiting the amount of concurrent tasks that can move through the system at any point in time can have massive impact.

Another valuable exercise to do is a Value Stream Map where you look at the flow from aha-moment to ka-ching moment. This can be a learning situation for all involved members as well as the organization around them.

Looking at the full end to end flow and having optimized that we can move on to the second way of DevOps.

The second way of DevOps is the Principles of Feedback

The first way of DevOps enables us to act on information, so the second way focuses on generating that information through feedback loops, and shortening those feedback loops to be able to act on learning while it is cheapest and has the highest impact.

Activities in the Second Way can be shifting left on security by adding vulnerability scans in our pipelines. It can be decomposing our test suites such that we get the most valuable feedback as soon as is possible.

We can also invite QA, InfoSec and other specialist competences into our cycles early to help architect for requirements, making manual approvals and reviews less like to reject a change.

Design systems are a powerful way to shift left as we can provide development teams with template projects, pipelines and deployments that adhere to desired guidelines. This enables autonomous teams to be compliant by default.

The second way is also about embedding knowledge where it is needed. This is a special case of shortening feedback loops. This can both be subject matter expert knowledge embedded on full stack teams, but it can also be transparency into downstream processes to better allow teams to predict outcomes of review and compliance activities.

A fantastic way of shifting left on code reviews, and improve knowledge sharing in the team is Mob Programming. Solving problems together as a team on a single computer. We can even invite people that are external to the team to our sessions to help knowledge sharing and to draw on architects or other key knowledge banks.

Now that we have focused on our ability to create flow and feedback we can move on to the third and final way of DevOps. The principles of continuous learning.

The first and second way of DevOps provide most of the technical capabilities for continuous learning and experimentation - so the hard work in the third way of DevOps is primarily cultural. Which makes it that much more difficult to do.

A small step could be to start talking about hypotheses that we want to test rather than tasks we want to do. We have a tendency to state things as fact and put them into our backlogs. This creates an unfortunate mental model and Taylorist Command and Control culture. Language shape our thoughts so let's start phrasing our backlog items as hypothesis. Rather than saying "Make Button A Blue", say "We believe making Button A Blue will increase clickthrough rate by 10%."

While the previous step can be useful the big theme in the third way is psychological safety. Making it safe to learn and experiment must be a priority if we want to have a healthy culture. We must make diversity a focus area, especially in the tech business we have a notoriously toxic culture.

We can measure Westrum Culture as described in a previous episode, and seek to address any shortcoming.

Learning, Diversity and Psychological safety must come from a leadership level exemplifying the virtues that the members of the organization must live. Otherwise, there will be no resilience and any benefits will be temporary. The impressive transformation of Alcoa embodies this perfectly.

Another simple, but difficult practice is to drive down the size of the work items you are working on. This will make it easier to create small self-contained experiments. This will of course put stress on your software and organizational architecture.If you want to finish with a concrete technical practice look into Chaos Engineering as described in a previous Episode. Chaos Engineer will help build resilience into your organization and is a structured approach to create more learning. As such it can bring some safer sandbox to practice learning and experimentation. This can be beneficial if the organization is quite far from psychologically safe. The three ways of DevOps: Flow, Feedback and Learning are a meaningful definition of DevOps and it even hints at a roadmap for DevOps Transformations. Use the three ways and the activities I have described here as an inspiration to kickstart or accelerate your DevOps transformation!

This has been the DevOpsDojo. You can follow me on twitter @randomsort. If you have any questions, feedback or just want to reach out and suggest a topic, do not hesitate. You can find show notes with transcripts, links and more at dojo.fm. Support the show by leaving a review, sharing this episode with a friend or colleague or subscribing to the DevOpsDojo on your favourite podcast platform. Thank you for listening, keep learning.