DevOps: the Culture and the Results

Lightning Summary

Defining the Culture

Google’s dictionary definition of culture is “the ideas, customs, and social behaviour of a particular people or society.” Let’s apply this definition to the society of engineers and people that work in software delivery…

  1. Empathy: Each member of the team understands the key pain points, pressures and blockers of other teams through retrospectives and they work cohesively towards the valuable global goal.
  2. Knowledge Sharing: Each aspect of the application lifecycle should know something about every other part of it in order to enable their own role, remove blockers or enable other subsequent steps in the value stream.

When it’s done good, what happens?

There are three main results of instilling the culture of DevOps, and if you want to know the rest, skip ahead to the results section…

  1. It’s not a thing: Each stage of the DevOps cycle does not become a big deal because it is repeatable, well-rehearsed and all members of the team collaborate to get the task completed.
  2. Strength in numbers: All teams with the development squad work together to deliver a high quality asset which is valuable to the business and there are measures in place to learn/prevent failures and mistakes.
We will follow that winding road ahead, let’s begin: Photo by Caleb Whiting on Unsplash

What is the culture of DevOps?

In Part I, we took some time to define what DevOps actually means and how we can combine application lifecycle with The Three Ways to create value for a business — hopefully we are all on the same page. Now let’s start to think about the culture of DevOps. This section is less about the abstract concept and more about the people who want to work in a DevOps environment, how they develop and how they operate (excuse the pun!).

Collaboration

What I am asking is that each member of the team should have a basic foundation and working knowledge of all the roles within the application cycle. Try not to hammer you team with pure feature development so that they have the opportunity to expand their knowledge base, understand the pain points of each role and work together toward a single goal. When a technical delivery team has a basic understanding of each role then they will develop empathy, take initiative when errors occur and deliver features faster.

Empathy

In Bartosz Jedrzejewski blog, An Organization’s Journey to a DevOps Mindset and Culture, he very nicely describes how connected teams can add value to a project more efficiently. Giving four steps to reach connected teams he says that “sharing knowledge is a key” because “they understand each other better [and] it helps to eliminate blame, build empathy and focus on solutions and improvement.” This shows that connected teams are empowered to work together better.

Knowledge Sharing

One way that I found useful to create a ‘one team’ philosophy is to hold Lunch and Learn sessions every two weeks where a member of each team shares knowledge about what they do and how they do it. When this was implemented, I observed the team performed better because we could relate to the work that was being done elsewhere. Creating the culture of empathy was vital to helping deliver key features within the application, especially since (like always) the tester was swamped. Developers and product owners took up the baton by assisting in creating test cases and writing scripts for functional or end to end tests. In this practical example, implementing a small knowledge sharing session empowered the team with a basic understanding of the responsibilities of the other roles. This meant we could collaborate to deliver.

The Results of Instilling DevOps Culture

So now you have got to this point and this is the juicy bit, the section that most people will be interested in. What are you going to see as a result of adopting the culture of DevOps? These are the things that you might want to look out for.

  • Cross functional teams: Having knowledge shared across the whole team means that a team member does not become a single point of failure. Each team member has growing knowledge in the responsibilities of others so the entire team can carry out processes that are documented or known.

Support Teams?

As a part of being a cross functional team, the team are also the best suited to fixing bugs because they understand the application best as they are the builders. This means that there is less reliance on external L2 support teams to develop fixes. The team has the capacity to work on fixes that are necessary because they are the best people to implement the fix, and they will be able to do it the right way. This effort will slowly reduce in time because the code quality will be increasing. Therefore overall there is less requirement to have L2 support teams to fix bugs and debug errors.

Dependencies?

One of the bigger impact results is that the DevOps team does not have dependencies on external teams and reduced dependencies within itself. With all teams members having a basic understanding of the responsibilities of the other roles then they can each carry out simple tasks to enable themselves. In some cases there might be self-service tools that have been developed for standard processes. A team member can therefore work faster because they remove the dependency on other team members, or external teams. For example, there are easily executable processes to create a database or there is a document on how to deliver hot fixes to production. This enables all of the team members to carry out these tasks and complete their delivery more quickly. Therefore, the team has a reduced amount of dependencies within itself and no dependency on external teams.

Don’t make it a big thing!

My mentor used to have this saying: it is not a thing. This resonated with me as I went through my journey in DevOps because DevOps enables processes so they don’t become a big thing. Each stage of the application lifecycle is well practised and each member of the team is well versed in what needs to be done. An example of this is releasing into production. One project that I worked on had an overnight outage for a release into production and lasted 24 hours in total. It was a big deal for the client, and they haven’t released again since then. However, if we had carefully designed a process for releases into production and practised them again and again, it would have become muscle memory and could be done blind-folded. Don’t make it a thing. Create a well known set of guidelines around an activity so that other people can also carry it out.

Make waterfalls like pebbles — its not a thing: Photo by Martin Sanchez on Unsplash

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nityananda Bashir

Nityananda Bashir

19 Followers

A practitioner of Bhakti Yoga, a DevOps engineer and a student to deeper experiences of happiness. I share stories, thoughts and practical lessons.