Avoiding the Slide From DevOps to DevOops

Comments 3

Share to social media

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.

About the author

Tony Davis

See Profile

Tony Davis is an Editor with Red Gate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the Simple-talk.com and SQLServerCentral.com websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his Simple-Talk.com blog or his SQLServerCentral.com author page.

As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management.

In his spare time, he enjoys running, football, contemporary fiction and real ale.

Tony's contributions