There’s no magic pill, quick fix or easy answer to creating a successful cultural change — and transitioning to DevOps is no exception.
DevOps isn’t simply about deploying digital tools. For a successful DevOps strategy, organisations must encourage debate, enable visibility and improve internal communications.
As the name suggests, DevOps describes a close collaboration between software development and operations teams in IT. The goal? To create a faster and more effective way of developing and managing software by delivering features, fixes and updates in a more efficient manner. But you’ve already heard about these advantages.
DevOps strategies and their success have been highly publicised, citing faster lead times, more frequent code deployment and quicker incident recovery times for IT teams. However, transitioning to this method of management is often approached incorrectly.
Deploying new technology is not the best approach
The emergence of DevOps as a buzzword has created a surge in new technologies, all claiming to make the journey from separate development and operations silos, to a collaborative approach, much simpler. But, deploying new technology isn’t necessarily the best way to begin this shift.
By nature, IT workers will favour technological tools as their preferred method of meeting business objectives. Tools are tangible, usually arrive with installation guidelines, and their purpose is well defined. Cultural changes, however, do not come with an instructional guidebook and can, therefore, be harder to implement during a DevOps journey.
Respect the differences
A common challenge of DevOps is ensuring both teams — development and operations —respect each other’s thoughts and opinions. Unlike technological tools, you cannot break personal habits or change attitudes with a simple update. Employees from both departments will come with past experiences and motivations which may be at odds with the mindset required to make DevOps a success.
To get around this, organisations should make the decision-making process simple and without hierarchy. Teams should be able to have an open and respectful debate, but fundamentally everyone will be working towards the same objective. Information sharing tools can, therefore, make the decision-making process easier, as actual production and build metrics will be visible to all.
Data is not subjective, so ensuring visibility of production will ensure that decisions are made based on actual performance information, rather than the personal opinions of workers in either team.
This reassurance through visibility can improve team dynamics, as it reduces the feeling of risk and uncertainty. In fact, when researchers at Google studied over 180 engineering teams, they found that the most important factor in predicting a high performing team is psychological safety or feeling safe taking risks around your team. In a relatively new area of collaboration, like DevOps, this sentiment could not be more critical.
Publish the good news
Cultural hesitations can also be made easier by publicising the success of projects which have been completed this way. Perhaps more importantly, organisations need to be clear about the benefits that DevOps is providing to specific teams.
Some workers can be short-sighted and will have a natural bias to strategies that clearly complement their own efforts. Communicating these advantages will differ between workers from development and operations, so organisations should consider this in their internal communications strategies.
The goal of DevOps is to deliver software quickly and efficiently. However, it is often misinterpreted as a strategy for deploying new technological tools to meet this goal. In practice, DevOps relies more on cultural acceptance than the integration of new tools.
Sure, the organisational change can be supported by a collection of software development practices, but organisations cannot rely on these tools. Ultimately, it starts with people’s mindset.
What are your thoughts? Further articles about DevOps have been published by Information Age and the links are below.
Author: Annie Andrews
Annie started her career in Microsoft training and consultancy, covering both programming and systems engineering. From here, she was a technical lead with many other technologies during her later positions at Lloyds Banking Group, where she held the role of Chief Subject Matter Expert. Now, Annie has returned to her mothership technology of Microsoft, as CTO at Curo Services.
The views expressed are those of the author and do not necessarily reflect the view and opinion of Curo Services.