DevOps: the Culture and the Results
Welcome fellow engineers! Welcome fellow people interested in technology! The following is Part II / III in a series of blog posts to inspire software delivery projects to practically implement the culture of DevOps. Here is a quick summary with links to the other parts…
Part I: Defining the term DevOps within the application lifecycle
Part II: Defining the culture of DevOps and describing its results
Part III: Practical actions you can take right now to start your DevOps journey
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…
The DevOps Culture is a set of ideas that can be applied within a complete development team to create an environment of collaboration, empathy and knowledge sharing which enables the team to deliver fast, reliable and valuable items to the customer
Now what does this definition mean for you? We defined in Part I what a complete development team is. Now let’s focus on the three environment adjectives in the context of DevOps team:
- Collaboration: The development team works towards a valuable global business goal, communicating with each other throughout all parts of the application lifecycle — whatever their role/responsibility is.
- 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.
- 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…
- A complete cross functional team: Each role gains skills and knowledge in other aspects of the application stack giving them the ability to perform simple and documented tasks that will enable their role.
- 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.
- 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.
Perhaps you are enjoying you lunch whilst reading this. I want to tell you the journey that I took to arrive to these essential principles of DevOps, care to come for a drive with me? Many engineers have taken this path to deliver success for their business and we will follow that winding road ahead, let’s begin.
I work at a huge technology consulting company and I have had the absolute privilege to work with a number of clients to increase their DevOps capability through technology and strategy. I have learned a lot about the difficulty when encouraging clients to change and the rewards that are reaped with hard, determined and continuous effort to invest in better software delivery.
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!).
The main principle of the DevOps culture is to be able to empower each role within the application lifecycle to learn about the responsibilities and skills of the others. This is knowledge sharing to create an empathetic team working in a collaborative environment.
Now, make no mistake, I know what you are thinking, ‘Wait, are you asking a tester to do the job of my ops guys? You must be mad.’ No, that’s not quite what I am asking, and perhaps I am a little mad, and I have to be to do a job like mine.
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.
When we create a connected DevOps team, each member of the team is delivering value to the global business goal because they are enabling the other team members through a culture of empathy. Having the knowledge of the responsibilities outside of their role empowers to take initiative with fixes and enable themselves by resolve their dependencies.
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.
Some of the obvious ones are:
- Improved code quality: By using fast feedback loops (e.g. test driven development when writing code), the team can catch errors before the next step in application lifecycle. Integrating unit test runs and automated testing means that the feedback to the developers on their code is faster, more accurate and consistent.
- 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.
We have defined the culture of DevOps to create a team which knowledge shares across this application lifecycle, thereby enabling collaboration and empathy. We discussed the results of implementing this culture mainly being improved asset quality and removing internal and external dependencies. There is one piece of the puzzle missing. One question left unanswered. How do we practically implement this culture? Read the next post here to find out what you can do right now to implement DevOps:
Part III: Practical actions you can take right now to start your DevOps journey
