# The DevOps Dojo DevOps, Modern Software Delivery, Common sense, Agile Software Development. Whatever we choose to call it, I believe we are in an industry filled to the brim with good practices, with engineers, teams, and organizations failing to apply them. This leads to sad, stressed, non-productive engineers in toxic organizations failing to deliver to their potential. Hopefully, this site will help you apply something that will improve your situation. ## Thinking about DevOps While DevOps orginally was about the chronic conflict between Dev and Ops, for me it is the umbrella term for everything that fits into enable modern software engineering in a healthy way. The content on this site, will of course, be very biased by how I think about software engineering, so I think the best way to handle that is to be transparent around my mental models. There are many definitions and models and so on about what DevOps _is_, and there is no authoritative source. My current state of mind is: > DevOps is the capability and practice of continuously validating business hypotheses in production environments, in a fast, safe and sustainable way. This is kind of boring, but I'll allow it. In the following two sections, I will first present the Three Ways of DevOps as popuralized by Gene Kim in The Phoenix Project. I will then describe my current mindset for adopting DevOps practices. ### The Three Ways of DevOps In The Phoenix Project, we follow Bill through a guided discovery of the three ways of DevOps, enabling him to save the day, the product and the company. It is a light read and should be on the reading list of most people who work with software. Or basically, who work - there are many insights. Maybe, there are also insights for people who don't work - It is a quite good book. The Ways that Bill discover are: #### The First Way of DevOps - Flow ![[Pasted image 20220408152400.png]] The first way of DevOps is about the ability to act. Moving things to the production environments, users or what ever we call the final destination of our software products. I like it, as this focuses on actually doing something, a basic capability many enterprise organizations struggle with. It also fits nicely into the idea that many organizations have stagnated to a degree where it is better to do something, anything really, than keep doing nothing. Practicing value stream thinking and orientation and delivery optimization also builds some healthy muscles and habits. #### The Second Way of DevOps - Feedback ![[Pasted image 20220408154041.png]] The Second Way of DevOps is about amplifying the feedback loops. Make sure that we get the feedback from the production environments and users. Injecting the information where it is needed. The second way is about being able to sense and understand the impact of our actions. #### The Third Way of DevOps - Continuous Experimentation ![[Pasted image 20220408154712.png]] The Third Way of DevOps is about exploting the two previous capabilities. Namely, we are able to act efficiently, and sense the impact of our actions. This enables us towards smaller iterations and experiementations. We should work towards adopting the scientific method of continuously hypothesizing and seeking verification of our claims. This allows us to out learn and out execution our competition. This way of thinking about adopting DevOps practices also gives shape to a _DevOps Transformation_ strategy. First, focus on removing the friction from delivering value to users. Second, focus on getting feedback as close to the value sources as possible. Third, work towards smaller and smaller iterations. Unfortunately, this is interpreted as many as _"Build Jenkins pipelines for everything"_ and they stop there. Overall, I believe The Three Ways of DevOps to be a healthy mental model for thinking about DevOps. ### The Structure of Scientific Revolutions The way I currently think about DevOps Transformation, or really any structured approach to changing culture and way of working of an organization, is heavily inspired by Thomas Kuhns "Structure of Scientific Revolutions", which Mike Long of Merkely was kind enough to introduce me to. ![[Pasted image 20220408152421.png]] In short, it treats how a science progresses. First, we have established practice or normal science. Then, we start observing phenomena, that doesn't fit into the established models. As the anomalies acrue, we experience a crisis as we fail to explain a larger and larger part of the world. And as David Deustch describes in his book "The beginning of infinity", human progress is driven by seeking _The Good Explanation_. As such, the crisis leads to a revolution, rejecting the _old_ normal science, leading to a paradigm shift through which the new world view becomes _normal science_. I believe that this way of looking at personalities or mental models, organizational cultures, or even how we perceive our systems is useful. So I present my three ways of looking at DevOps. #### Learning to see the anomalies Recently, I listened to an episode of the podcast 99% Invisible. It is fantastic, and should be in your feed. In it, Alexandra Lange say the following: > I would see people, you know, tweeting pictures of birds from Brooklyn Bridge Park. And so I’d think, oh, I should, you know, notice those, but I just… it’s like, I didn’t know how to notice them. > -Alexandra Lange Source: https://99percentinvisible.org/episode/murder-most-fowl/transcript/ To me this is profound. In many cases, the reason we fail to act, is because we fail to see. Over time our team culture, org culture or personal mental model becomes more and more resilient. More resistant to change, better at maintaining status quo. This is natural, but problematic. I hope through this site to give you many new ways to see and appreciate the anomalies, such that you can act in new and exciting ways. The first thing we need to do, is being able to recognize anomalies. Things that do not fit our mental model. ![[Pasted image 20220408160258.png]] At first, a single anomaly will often be rejected, but the goal is to see, recognize and inspect anomalies. When we see something unexpected, or that does not fit with our world view. We must reject our impulse to reject the anomaly. This also fits into the Westrum Typology of organizational cultures, where one of the indicators of a healthy culture is how we react to novelties. #### Acting on the anomalies So the next thing we want to do is to _act_ on the anomaly. That is we want to expand our current model to also contain the anomaly, should it not be considered truly an anomaly. ![[Pasted image 20220408160748.png]] This could be through implementing something differently or changing our processes or perception around something. A common pattern is the mental model of _"We are a state of the art software organizations"_, which requires of so many anomalies for anyone to take notice. We should then take advantage of the anomalies that show us things we can't to as well as someone, and implement those practices. Or change our model to "_We are a mediocre software organization_", and use that as a stepping stone to become excellent, once again. #### Generating Anomalies Now that we can see and act on anomalies, our goal should be to generate as many anomalies as possible. We want to have as many Kuhn Cycles as possible, in order to out learn and out execute our competition. ![[Pasted image 20220408161158.png]] There are many ways to generate anomalies. Hire people that do not look like you. Join industry networks. Go to conferences and meetups. Host meetups! Hire consultants that can bring an outside perspective. And as your mental model grows, some of the expected anomalies will lie inside of your already established model. I believe this is a sound way of thing of DevOps Transformations and Cultural Change, in a way that if addressed right will allow you to iterate to the frontiers of whatever field you may be working in. Overtime, I hope to add more content to this vault, helping you see in new and different ways. Maybe, just learning about one new perspective will help you see many anomalies that were already there.