One of the key goals of DevOps is to reduce the gap that exists between Dev and Ops. It is what causes water-SCRUM-fall, when it comes to the Dev and Ops communication and collaboration. (The gap between corporate teams like EA, Security and other ‘approval boards’ and ‘gates’ is another story for another post). Whether you are a small shop with a small team of overworked Dev and Ops practitioners; or a large organization where Dev and Ops are massive teams under different management chains altogether, this gap exists. For the small shop, it may be just getting Dev and Ops to find the time to talk outside of just deployment time. For the large organization, it would be creating communication channels outside the management hierarchies that separate Dev and Ops. Either way, transforming how these two organizations collaborate and communicate is a requisite component of DevOps adoption. This does not mean the creating of a new cross-organizational ‘DevOps’ team (although that is a viable option to explore). It means transforming how these teams interact, collaborate and communicate with each other. It means transforming how these teams are managed and potentially even how they are compensated.

Dev vs Ops?

Historically, most organizations have struggled with this Dev-Ops relationship/alignment. The reason for that is very understandable. Dev is tasked with the job of producing innovative capabilities and automating business processes for speed and efficiency. Ops on the other hand is tasked with making sure the systems these applications run on are stable, available and responsive. Dev is measured on the change they create. Ops is measured on the stability they provide. Dev is ‘dinged’ for not producing change on time or not producing enough change. Ops is ‘dinged’ for instability or downtime of the systems or unexpected change. Dev wants to introduce new capabilities and features as soon as possible. Ops wants to keep stability at all times. Reasons enough to butt heads.

Then again, I am not suggesting that these differences are in-reconcilable or even that they are like opposing teams. After all, their individual goals are just two faces f the same coin. Both Dev and Ops are the to provide a system that adds value to their customers and/or users. They just have to communicate and collaborate more to make sure they align and work together to make this happen. Communicate enough to ensure Dev brings about innovation keeping Ops in the loop on the changes Ops will need to make to enable those innovations and Ops need to get more involved in the processes of Dev and get more visibility into what Dev is building so they can preemptively make the changes they need to make to deploy what Dev produces. Work as a team!

Organizational Change:

One of the reasons this is a challenge is that in most large companies Dev and Ops have been separated by a pretty large organizational ‘wall’. They are typically in separate management chains – Dev being in a CTO or VP of Dev’s organization and Ops in a COO or VP of operations’ organization. This results in hindered communications. In outsourced organizations, Dev and Ops maybe totally different sets of (multiple) vendors who never talk outside of a change management tool and contract based negotiations of responsibility! I recently met with an company where a project we were looking at had three different vendors responsible for development, QA and infrastructure respectively. This is a normal arrangement for the whole company, which has less than 20% of its IT staff made up of employees. Not much Dev-Ops collaboration going on there.

So, how does one do it? Adopting DevOps takes considerable transformational change in the organization. There are a few key principles in the DevOps space that must be used to form the basis of this transformational change. I will discuss them in the next post.

Do you see an effort to align Dev and Ops going on in your organization? What kind of Organization Change is going on? Does how Dev and Ops teams are measured and compensated need to be re-aligned too? Share your thoughts by leaving a comment below.

Like to learn more about Adopting DevOps? Check out my new book – The DevOps Adoption Playbook.

Related Posts:

Understanding DevOps:

• Understanding DevOps – Part 1: Defining DevOps
• Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
• Understanding DevOps – Part 3: The Battle of Dev vs Ops
• Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
• Understanding DevOps – Part 5: Infrastructure as Code
• Understanding DevOps – Part 6: Continuous Deployment

Adopting DevOps:

• Adopting DevOps – Part I: Begin with the Why
• Adopting DevOps – Part III: Aligning Dev and Ops Teams

DevOps books I have written:

• DevOps For Dummies (Free download, courtesy of IBM)
• The DevOps Adoption Playbook (Link to Amazon)

Other DevOps Posts:

• DevOps 101 – Concepts and Basics (Slides from IBM Innovate 2013)
• What is Water-SCRUM-Fall?
• Leveraging DevOps in a water-SCRUM-fall world
• Monetate’s 12-step program for Continuous Delivery
• The State of DevOps (by PuppetLabs)
• DevOps for Mobile Apps – Slides from IBM Pulse 2013
• Chef for DevOps – An Introduction