Avoiding the Slide From DevOps to DevOops

If you roll out DevOps across an organization before it is culturally prepared for it, you will see warning signs that the initiative is failing. These are:

  • Team members complain of unmanageable workloads
  • Requirements, quality management and metrics get neglected; customer complaints increase
  • You promote and reward the ‘firefighters’ rather than the staff who prevent bad things from happening.
  • Your DevOps practices don’t work with ‘legacy’ technology.
  • You have pockets of DevOps practice in just a few teams
  • You feel the need to appoint specialist ‘DevOps’ people to sort out the issues
  • You suddenly find that you’ve lost your testers
  • Your developers talk more about NoOps than DevOps

What are the underlying causes of these painful symptoms? Lack of technical skills? Or of effective automation tools? In fact, it’s more likely to be ineffective teamworking. It is “soft skills”, not technical, tools or automation skills, that are the biggest factor in determining the ease or pain with which an organization can “switch to DevOps”.

This goes against many of our instincts as technologists. DevOps can seem at first to be another unruly aspect of the universe that can be fixed with technology. Bob Walker illustrates this admirably in his articles describing the introduction of DevOps to FCSA. The fun part was imagining the ability to “deploy to production 10 times a day ” and the technologies, cloud services, and the collaborative scripting, automation, monitoring tools that would help them get there. The hard part was defining their DevOps in a way that won support from all sides. Not everyone trusts the real motivation for such change.

So how can we achieve the hard part? Much is down to the old-fashioned arts of effective communication. As Grant Fritchey puts it, “Show what you’re learning. Show what you failed at. Show what you succeeded at. Share your knowledge with others.” Whereas other professions give training in such teamwork skills as communication, arbitration, empathy, compromise, and tactful persuasion, they are less in evidence in IT.

DevOps requires these teamwork and communication skills by the bucket load. If we can find better ways of facilitating communication within teams, then misunderstandings and tribalism as less likely to happen. Communication and coordination Tools such as Slack, Trello and Jira are evolving to the point of becoming the “operating system of the business”. Some operations teams are already using tools like Slack or HipChat to automate and document basic infrastructure changes, using bots and “slash commands“. The resulting text is and searchable and helps to explain to others not just what’s happening, but how and why. The automated processes can directly communicate their progress and outcome.

DevOps can make spectacular improvements in the speed and quality of the delivery of software, but it is the power of good teamwork and realistic workloads that makes it work. Sure, automation will help but it will only help an organization whose members are enabled to work cooperatively. It must support the teamwork and make the team processes more visible. Automation becomes the servant to the team, not its master.

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.

  • 2768 views

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

    It helps to choose the right automation tools for the job as well. Just as we tend to fall into the “TSQL Hammer” trap as SQL Server users, I’ve seen several choose the wrong tool just because it was familiar. That made automation much harder in many cases. Documentation hasn’t been too hard with decent wikis, files with the source control, and comments in the code.

    The biggest hurdle overall is communication. Too many times the devops team consists far too much of either “dev” or “ops” and they don’t collaborate too much once the initial pain is past. It takes a great effort to keep things open – both in choosing new technology for dev and in working together to implement it well on the ops side. If that doesn’t happen you tend to get resentment again in the feeling that rules are being made or decisions made without the other side’s input.

  • willliebago

    Good communication is the one thing companies need the most
    and usually the thing they do the worst. Poor communication is cited as a one the
    biggest mistakes companies make in managing people. It is the heart of morale
    problems and it is also the reason behind half of all unsuccessful projects.

    Effective communication is the key. Doesn’t matter if implementing DevOps or waterfall
    SDLC, communication & teamwork will determine success.

  • Keith Rowley

    I wonder how AI is going to change this, especially when we have an AI (or several) as full fledged members of the DevOps team. I tend to think clear communication will be even more important at that point.