Bridging the DevOps Divide

What’s the main obstacle to implementing a DevOps approach in your organization? In a recent “State of DevOps” survey conducted by Redgate, the second most popular answer to this question, after “lack of skills”, was “lack of alignment between development and operations teams“.

Hmm, so you can’t do DevOps until you have a DevOps culture. It’s an organic, culture-driven process and a culture only tends to infuse an organization through practice, so surely one is left trying to put the cart before the horse? It feels like a slightly crazy situation, but there are perfectly reasonable explanations for why it arises.

As William Brewer points out, no development methodology, Agile or Waterfall, has ever advocated having a ‘Chinese wall’ between operations and delivery, and yet it exists in many workplaces, mainly as a natural consequence of human nature, and organizational expediency. Development and Operations have traditionally had very different business objectives. The Dev team with a narrow focus on delivering a particular application, the Ops team with a much broader remit to maintain the security and smooth running of all of the organizations business systems, and ensuring the correct ‘distribution’ of limited hardware budgets and resources across all teams and business applications competing for these resources.

I think that the survey answer masks a very real difficulty: development teams and operational teams are already fairly closely aligned in organizations that have a single application that is being developed in-house, and which dominates the business. Where an organization has a whole range of applications, mostly bought in, but essential to the business, together with several active development projects, it just doesn’t seem so clear-cut. The objectives and priorities of Ops and Development are bound to be different. It is unwise for a company like this to pretend to be a start-up.

So just how does an organization who sees value in DevOps practices overcome this lack of alignment between development and operations teams, without suddenly trying to behave like a startup? How can you encourage good people to work together without artificial boundaries? First, you need to be clear about which IT processes, such as deployment, actually require Dev and Ops to work together. Then, find simple ways to start collaboration, one project at a time. I like some of the ideas expressed by Bob Walker in describing the process of DevOps adoption at Farm Credit Services of America. They were able to express their DevOps goals in one very simple question: what needs to change in order for us to be able to deploy to pre-production every 45 minutes? Developers, DBAs, web admins, mangers, everyone were encouraged to contribute their opinions. With a common goal established, suddenly the conversations started.

Ultimately, if your teams are already cooperating whenever necessary, then it’s easy to introduce DevOps; but if they are already cooperating, then maybe you see no need to do so! Perhaps we can best encourage a DevOps culture just by making sure that cross-function cooperation is actively rewarded and encouraged by management. Tell me there is more to it than that!

Commentary Competition

Enjoyed the topic? Have a relevant anecdote? Disagree with the author? Leave your two cents on this post in the comments below, and our favourite response will win a $50 Amazon gift card. The competition closes two weeks from the date of publication, and the winner will be announced in the next Simple Talk newsletter.


  • Rate
    [Total: 2    Average: 5/5]
  • Peter Schott

    We had an additional requirement beyond just speedy releases. Those are important, but we were also regularly hitting times when devs would want new tech that would need to be supported by the ops team or the new tech would need new hardware that would need to be procured or some similar desire. Our DevOps initiative wasn’t driven by the teams being silo’d so much as that they just needed to do a little communicating up front. Having an ops member sit in on the sprint reviews or planning helped because they could ask questions about how the tech would be implemented or at least _know_ to ask those questions then instead of when everything was ready to release and that’s when the new tech was revealed.

    I think we actually were doing a pretty good job at this before there were some major changes that affected the company and disrupted this process. There was a lot of respect between the teams and a lot of thinking of the sort “how will this affect Dev/Ops” whenever new ideas were considered. I agree that a goal helps as does removing some of the silos that get put in place so one team can reach out to the other team and have good conversations – not to the point of taking up all of their time, but enough to make better decisions for everyone going forward.

  • willliebago

    I don’t think there is any more to it than timely communication. How do we measure cross-functional cooperation so that it can be actively rewarded?

  • Keith Rowley

    As with most things in business, and lots of things in life, good communication and “soft” people skills seem to be the keys here.

  • rogerthat

    The key experiences I have personally had as a developer that has led me to embrace DevOps are: far fewer mundane support tickets that can easily be solved either by a script or first-level intervention; not a single missed breaking change thanks to continuous integration – I have ceased to have to fix other’s breaking changes; fast spin-up sandbox times for new developers; an increase in tickets that indicate a problem exists that no human had to point out.

    As cheesy as this may sound, it really helps to have a mission that everyone can get behind and see as a solid reason to move beyond
    the comfort zone and see the effort needed is a worthwhile team goal. Our best efforts were also seen when we had admins and developers as team members, mixing the roles helped. It is worth the effort!

  • The most important ingredients have to come from engineers, not management.

    Do your ops and dev teams eat lunch together and discuss common gripes and issues or do they eat separately and complain behind each other’s backs?

    If you are an engineer in either a dev or ops team when did you last take some of your free time to sit down with someone from a different function and just chat? Do you ever meet your opposite numbers socially? Do you ever talk about common problems or discuss how you could support each other?