The Inside Out of DevOps

Everybody wants DevOps! Introducing new stuff in any organization is always challenging though.

It is an adventure, and you will have a rag-tag bunch of companions on your journey. Using the crew from Inside Out we’ll look at these characters, and how you can make a great travel companion out of anyone!

The DevOps Detour

Before we can get started, we probably need to talk a bit about this DevOps thing. There is a lot of arguing about the definition of DevOps. For the purposes of this blogpost let’s say that DevOps is a set of practices that favors automation, a holistic application view, and velocity in software development and deployment. So it is about developing software, delivering it to customers, and making sure it keeps working after delivery.

We believe that DevOps and Continuous Delivery will be just as important as Agile has been for the industry. Developers will look with confused resignation on organizations that do not do Continuous Delivery and DevOps. So let’s take a look at the characters that you might encounter on your journey towards modern software development.

Welcome to Headquarters

In the movie Inside Out, we’re inside the head of a girl called Riley. The primary emotions Anger, Disgust, Fear, Joy and Sadness have a shared control panel, the combination of these different perspectives make up the personality and behavior at Riley. While these emotions are an obvious simplification, they have helped many better understand how emotions work. So let’s try to apply the same reduction to the DevOps transition in a tech organization.

Joy

In the world of Joy everything is awesome. Joy is a first mover, always tinkering, and typically better at starting things than finishing them. It is necessary to have Joy around, we need the everything is awesome mentality. But we also have to remember that different isn’t good by itself.

We need to continuously reflect on the choices we have made and not just keep running towards a shining goal. It is important for any change process that we at all times are aware of why we are doing what we are doing, and how that is aligned with the overall goal. We are trying to solve some problems, we are not just grabbing a bag of new tools for the sake of doing something.

People with the characteristics of Joy tend to be Technology Apologists. Very impressed that a tool works or exists, but not necessarily observant of the (lack of) maturity or usability. The term Technology Apologist was coined in the book The inmates are running the asylum by Alan Cooper.

It can be hard to keep a Joy in line and working in accordance to the established processes. Joy can be used as a canary of issues to come. Make sure it is so easy to do things the right way, that Joy can’t help but create that Jira issue for the improvement she just came up with.

Favourite Quotes from your Joy character:

• ”This is how they do it at Facebook”
• ”I found this new tool”
• ”I read on HackerNews …”
• ”Oh, yes, that doesn’t quite work yet, but […]”

Joy’s favourite tools:

• Something she compiled herself from some repository with code written in a hip language like Rust or Go.

• Alternatively, Vim.

Anger

Anger gets sh!t done! You can be sure that if something is broken you will hear it from Anger. If colleagues of Anger are not quite adhering to coding style, or waste time at meetings, it will not go unmentioned. Anger is very productive, but it can be a very uneven road running with Anger. Productivity tend to go down when you have an Angry developer standing at your desk at regular intervals.

A way to treat Anger is to make sure that you are aligned with Anger and that Anger does not have unrealistic expectations in terms of the maturity of what they work with. It is also very important to not let Anger drive all your decisions. In that case you will be fluttering like a firefly to extinguish the fire du jour.

You need to remember though, the Anger does not come out of nothing. Figure out the root cause and address it. Figure out what drives Anger and he will be a powerful ally. Anger gets sh!t done!

Favourite Quotes from your Anger character:

• ”The pipeline is broken”
• ”Who broke my build?”
• ”I’m not gonna wait for IT any longer, I’ll buy my own server”

Anger’s favourite tools:

• The print screen key
• Outlook
• Walking to your desk

Disgust

Disgust serves a very important purpose, to keep us from getting poisoned. It is a healthy trait to have a certain skepticism regarding new tools or procedures. As many change agents have tendencies towards Joy, we feel that Disgust is very backwards. They are too hesitant for us to work with them in a meaningful manner. But in many ways Disgust is the barometer for success. Remember that at one point in time what is now status-quo was new and disgusting.

Until we can convince Disgust, the transition towards DevOps is not going in a delicious direction. And as DevOps is something that we sprinkle on top, it should be delicious. It should be the case that what we are moving towards is more attractive than status quo.

We need to decipher the origins of Disgust’s skepticism, and cut out the poisonous parts. Or boil them hard enough that they will become unrecognizable. Make small improvements for Disgust. Make a Git alias or a little script to take away some of the pain.

I’m sorry to say it, but this might be the point in which you end up taking screenshots and put them in a Word document or PowerPoint.

Favorite Quotes from your Disgust character:

• ”This looks awfully like a tool from the ‘90s”
• ”This new setup looks very complex”
• ”Don’t think that just because it works other places it works here”
• ”I’m not sure that it provides value to the company that I learn Git. It is for people like you”

Disgust’s Favorite tools:

• The IT-department approved IDE
• Sharepoint

Fear

Fear is important. Fear prevents us from getting hurt. Our experience is that Fear tends to look at what is the safest path in the short term. For many companies the safest thing might be to keep working in SVN. Keep working as we usually to. But that will hurt the business in the longer term. Fear sees through the “Ops” point of view. We have something that we need to keep running. That is the most important part of everything that we do, because otherwise how can we provide value to our customers? Fear likes stability above all.

An important thing in dealing with Fear is to not do something unexpected. Make sure that you have a clear and transparent roadmap with a timeline. Be honest if you know that the next short timespan, there will be bumps in the road. That way Fear can prepare for it.

If possible involve Fear in the change process. And then when you are the utmost annoying with Fear being a pedantic prick, remember that everything Fear catches and points out, is a lot cheaper than fixing what went into production.

Favourite quotes from your Fear character:

• ”I don’t think it will work”
• ”It works now, why change that?”
• ”I’m not sure picking an Open Source tool is such a good idea”
• ”How will we know that […] ?”

Fear’s favorite tool:

• Excel
• Visual Studio 2010
• A fourteen page Word document describing an install process

Sadness

Sadness is what brings context to Joy, sadness is what brings reflection. It is not until we encompass this and make a balanced whole that we will be a successfully DevOps organization.

Sadness is the necessary counterpart to the Technology Apologist Joy. She makes sure that we do not forget why the last transition failed. And to Joy this will feel like a miserable nay-sayer. But that is not the purpose of sadness.

As Sadness says ”Crying helps me slow down and obsess over the weight of life’s problems”. And this is how it feels. But if we do not obsess a bit, if we do not go through our retrospectives honestly, remembering both pains and prides. How are we supposed to improve? How are we supposed to succeed. Sadness gives us all the important learnings that we need to be better next time.

I am Joy at the core. I start things, get distracted, start new things. Sometimes forget that there is also a reality that needs some love and care. I have to be very careful that I do not try to just put Sadness in the chalk circle and say “don’t disturb my progress”.

I get annoyed when I (again) have gotten this awesome idea, and I present it to somebody who turns out to be a fact-driven realistic, level-headed guy. It helps me figure out what ideas are important and what ideas might be best left at that. Ideas.

So respect and acknowledge Sadness, there is much truth to be found from them.

Favourite quotes from your Sadness character:

• ”In the last transition we forgot ..”
• ”Remember that everyone needs to get onboard”
• ”There was a huge hassle last time we changed tool because ….”
• ”The pain is still there with the new tool, just at a different place in the process”

Sadness’ Favourite tool:

• Memory of what have been tried before. The comprised set of pains of transitioning from the day the company started till now.
• A coffee mug from a tool vendor long gone

Bing Bong

Bing Bong is the imaginary friend of Riley. No longer relevant he sacrifices himself for the sake of the mental health of Riley.

As such we can see him of an example of the code base or tool stack that has been. It was important, and at a point in time was the most critical part of the way that the organization worked. We should make our decisions based on the lessons learned when Bing Bong was the king of our streets, but we should not try to artificially preserve him, or for that matter maintain restrictions imposed by the way we used to work.

As long as we recognize that the tool stack that we painstakingly have cobbled together over the years is what enabled us to get where we are, we should be able to, in good conscience, say good bye to it, and move on to DevOps. This is a difficult realization to obtain, especially in companies with codebases that had their first lines of code before companies like Uber or Tesla, were even founded.

We must acknowledge all the decisions, that were right at the time, that led us to this mess we are in now. And we have to acknowledge that we can move much further by changing.

Going towards DevOps

If you are on the journey towards Continuous Delivery and DevOps and need some sparring, or if you are just trying to figure out how to start, please reach out. We have a lot of experience of being a valuable travel companion in those journeys.

If you see yourself or one of you colleagues as one of these characters, please give us your favorite quote from them.

We wish you godspeed and great mental health.

All images in this blogpost are from the movie Inside Out. Copyright: ©2015 Disney/Pixar.