DevOps Culture

A DevOps transformation is achieved by making organizational changes across People, Process, and Tools.

A big part of the DevOps discussion is the concept of implementing a DevOps culture across organizations.  Unfortunately,  I often hear it as something that should just happen.  “We will take care of the process and tools, you go and focus on the DevOps culture”.  How do we define that DevOps culture?  What does it mean to have a DevOps culture?  Who implements this DevOps culture?

Collaboration_thumb2

Your organization’s culture of DevOps will often be the defining factor on whether you will have a successful organizational change or whether the changes that you implement impact pockets of your organization.

So what exactly do we mean when we say DevOps culture?

Let’s talk about the behavioral changes that we are looking for when we talk about DevOps.  At the core of DevOps, we are looking for increased collaboration. Sure, this is collaboration between Development and Operations, but it goes way beyond that.  Collaboration across teams often times involves breaking down walls (physical and virtual) and changing behaviors across the organization.  Collaboration between Development and Operations can start with a conversation and shared goals and priorities.  We want collaboration between Dev and Ops to extend to the way that we design and implement systems, to the way that we deploy software, to the way that we monitor its effectiveness in production, to the way that we think about new servers or services that will be needed to support new features.  As teams start thinking about these things, they often shift towards a a Production-first mindset.

What process changes foster this DevOps culture?

Gears-Turning-medium_thumb2

As your team looks to shorten the cycle time between an idea and production, think about the things that are preventing you from getting there.

  • Branching Strategy: It could be that your branching strategy does not allow your teams to work on multiple features at the same time.  Decide if you are using a version control system that aligns with what your company need, and within that version control system, determine if your branching strategy fosters collaboration and your ability to work on and deliver multiple features.  Follow the code from each branch, through code review, build, deployment, all the way through production, and find bottlenecks or opportunities for process improvement.
  • Environments: Do you have the right environments to support your development, testing, and overall delivery?  This is a great opportunity for Dev and Ops to work together and define an environment strategy that will provide teams with a way to collaborate and create feedback loops.  We are looking for repeatability and agility, so these environments should be created in an automated way.  Your applications and databases would then be deployed continuously as part of your release pipeline. Another great opportunity here is to leverage the cloud as a tool that can enable agility.  Move away from thinking of your infrastructure as a fixed resource and, instead, think of it as a flexible and powerful resource.  Azure offers ARM templates, which give you a way to create Infrastructure as Code.  Dev and Ops can work very closely creating these automation scripts and templates, which can and should be applied across all environments.  As soon as you need to add new services to support your application functionality, developers can make a changes to their Infrastructure as Code scripts and have those changes go through a code review process where Ops verifies and approves changes.  We then apply those changes across various environments until they make it to production along with code and database changes.
  • Automation: Automating manual processes enable collaboration, automation frees people up to work on high-value tasks and helps you have a repeatable process. Manual processes are error-prone and if you are trying to achieve continuous deployment, automation plays a very important part.  We don’t implement automation just to say that we have it automated, we automate all things to help teams deliver faster, teams enable quality practices through automated tests, and to enable those very important feedback loops between team members and between the delivery team and the business.
  • Measure: How do you know if you are delivering value if you cannot measure it?  What does value mean to your organization?  If you added a button to your page, do you know how often your users are clicking on it?  And once they click on it, is your application behaving the way that you expected it?  These are things that Dev and Ops teams should collaborate with to make sure that developers are adding the right instrumentation and that operations can access metrics and are able to quickly take action based on what is communicated by your application, and provide developers with enough information to continuously improve the application.  This requires team members to work closely, without a wall in between them and with a shared set of priorities.

Is DevOps all about Dev and Ops?  What about the rest of the organization?

DevOps transcends just development and operations.  A DevOps mindset and the changes and improvements that can be achieved with a DevOps transformation is something that impacts the entire organization.  DevOps changes the way that your organization develops ideas and turns them into products, the way that initiatives are prioritized, how we think about quality, how we think about alignment across the organization.  At the core of it, DevOps fosters collaboration across the organization, an organization with no silos and where everyone is aligned and aware of the organization’s direction and how they fit into achieving the company’s goals.  We deliver through continuous feedback, enabling automation, always thinking about quality, and constant alignment across the organization.

What about the DevOps team?

EnableCollaboration_thumb2

Often, as companies introduce DevOps, they create a DevOps team, or perhaps there’s already a DevOps team that has the role of automating deployments.  Creating a team with the purpose of “doing DevOps” goes against what DevOps is trying to implement, you are creating yet another silo and another potential bottleneck since now that is the team that is in charge of automating, measuring, creating environments, collaborating, etc.  You are trying to create a DevOps culture, one where everyone across the organization has a DevOps mindset.  So your DevOps team is there to enable the organization to achieve this, spread the culture and practices, rather than being the only team that is doing DevOps.


Is your organization going through a DevOps transformation?  We can help!  Nebbia’s DevOps consultants can help you shorten the cycle time from an idea to production and put your organization in a position to succeed with DevOps!  Contact us at hello@nebbiatech.com.

By |2018-03-07T15:02:22+00:00November 5th, 2017|

About the Author:

Founder and Chief Technologist at Nebbia Technology. Esteban has a passion for ALM, TFS, Azure, and software development best practices. He is a Microsoft Visual Studio ALM MVP and ALM Ranger, Pluralsight author, and the president of ONETUG (Orlando .NET User Group).