Understanding the DevOps transition
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!
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.
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.
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.
Something she compiled herself from some repository with code written in a hip language like Rust or Go.
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!
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.
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.
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.
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.
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.
Had enough of sluggish polling? With instant Artifactory event triggers you can give responsiveness in Jenkins a real boost. Here’s an easy way to set it up.
A super easy configuration guide
With the arrival of microservices code is becoming disposable. Does this mean that we no longer need maintainable code? Is it the end of refactoring?
Still relevant or increasingly redundant?
In software development tight coupling is one of our biggest enemies. On the function level it makes our application hard to change and fragile. Unfortunately, tight coupling is like the entropy of software development, so we have always have to be working to reduce it.
How to safely introduce modular architecture to legacy software.
I am an Atlassian certified trainer and over the years I have been spending much time with clients and their Jiras. In this blogpost, I have collected some small tips and tricks that will make your Jira usage better.
Jira Software is a powerful tool deployed in so many organizations, yet in day to day usage people are missing out on improvements, big and small.
In this post, I’ll take a closer look at the version of Jenkins X using Tekton, to give you an idea of how the general development, build, test, deploy flow looks like with Jenkins X. How does it feel to ship your code to production using a product coming from the Jenkins community that has very little Jenkins in it?
A crash course in Jenkins X and how to test it out on a local Kubernetes cluster
In this blog I will show you how to create snapshots of Persistent volumes in Kubernetes clusters and restore them again by only talking to the api server. This can be useful for either backups or when scaling stateful applications that need “startup data”.
Sneak peak at CSI Volume snapshotting Alpha feature
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Writing tests for ‘Theatrical Players’
Nicole Forsgren and the Accelerate DORA team has just released the newest iteration of the State of DevOps report. The report investigates what practices make us better at delivering valuable software to our users as measured by business outcomes. Read on for our analysis of the report, and how it can be best put to use.
The latest drivers of software delivery performance
A major challenge of software development is that our work is by and large invisible. This makes our folklore essential in business matters. Some of our commonly used arguments and visualizations are digital urban legends rather than solid foundations for informed decisions. Here, we’ll go through a few examples and some measures to address our misconceptions.
How the stories we tell influence our decisions
When you embark on your cloud native journey there will be important choices to make about cloud providers, continuous deployment, environments’ setup and separation. This guide will help you make the right choices by sharing lessons learnt from running cloud native apps in production.
Kubernetes has become the de facto container orchestration platform. When we help clients of different sizes and domains start their cloud native journeys in Kubernetes, we assist them in making sound decisions and technology choices. There is no one-size-fits-all solution when it comes to choosing cloud providers, CI tools, continuous deployment pipelines etc., so it is important to make the right decisions at the start. Failing to do so can be very costly in terms of lost time and money.
How to make the right technical choices on your cloud native journey
Learn how Docker and Kubernetes work and the key benefits they bring. Using real demos, I show how Docker is a great packaging and distribution technology, and how Kubernetes provides a powerful runtime for containerized applications.
Watch this introduction to Docker and Kubernetes at the Trondheim Developer Conference (TDC)
In the world of Agile and DevOps we use many figures, charts and diagrams to argue and reason about our world and how we prioritize and make choices. However, at all levels of the organization, we misuse and misinterpret figures. It’s time to be explicit, measure the right things and act on them. Watch this talk from DevOpsDays Zurich in May 2019.
Watch this talk from DevOpsDays Zurich
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps