8 November 2018

Preparing for DevOps culture change

OPTNZ 180918 354

By Sophia Hobman, Test Practice Lead

DevOps is fast emerging as a better way to deliver quality software to customer expectations, on time and on budget, through processes of continuous deployment. Building on the success of SCRUM, Lean, and similar Agile approaches to software design and development, it brings agile philosophies to the realm of operations and infrastructure. DevOps and continuous deployment are a radical transformation from traditional ideas about how to manage operations and production environments. This requires a step change in cultural values, and it means that any successful DevOps initiative has to consider the impact on people and the way they work, as well processes, tools, and technologies.

What is DevOps?

In essence, DevOps automates the build and deploy processes, taking code all the way from development to production. Through automating all the environment build, deploy and test processes, operationally ready code and deploy processes can be tested many times before getting to production.  This increases the quality of releases and enables release activity to occur with more predictability during working hours. At companies like Amazon, Facebook, and Google, this model of continuous delivery is critical to their strategic capability.

How does DevOps affect people and culture?

According to one standard definition, DevOps 'emphasizes the collaboration and communication of both software developers and other information technology (IT) professionals while automating the process of software delivery and infrastructure changes'. That means people on the 'Development' side - including the customer, business analysts, software architects, and software developers - working in close harmony with infrastructure, network, and operations specialists throughout the software lifecycle. This is a marked contrast to the traditional approach of completed software being 'thrown over the wall' into operational deployment, sometimes with little certainty that what has been developed will work in a production environment or will deliver what the customer expects.

DevOps success factors

Breaking down the silos between development and operations to create open, productive communication and collaboration may require some deep change to the way people think about themselves, each other, and their work. A few key success factors include:

·       Foster trust and transparency within and between teams

·       Understand people's motivations

·       Move away from a blame culture while ensuring everyone understands and learns from what went wrong

·       Identify and remove bottlenecks, whether they are caused by people, processes, tools or (most likely) some combination of these

·       Create an environment where continuous innovation is enabled by the willingness to allow failure. Embracing 'fast failure' and the ability to identify and fix problems early and easily, is integral to DevOps success.

·       Build and empower cross-functional teams

Easier said than done, right? In future articles, we'll be sharing some practical advice on how to achieve this deep culture change using a variety of tools and strategies. These can include team workshops, self-assessments, and new staff incentive practices.

Putting to rest DevOps fears

With DevOps promising greater collaboration, higher quality software, and faster deployment, you may well ask what's not to like? But such a profound transformation in the way people work and the way their working environment is structured can also bring anxieties. These need to be recognised and proactively managed. For example, a common concern from the operational side is that developers will be taking over their jobs. This is simply not true. Really, it's a case of the learning and benefits from agile development now being extended into operations, going beyond the code to the entire service delivered. Customers are now demanding business agility and the agile services to support it across all aspects of the engagement. DevOps principles, processes, tools, and practices give operations and infrastructure teams a roadmap to transition from outdated, overly rigid approaches, and allow them to demonstrate the value they add throughout the software lifecycle.

DevOps is strongly orientated towards automating as many aspects of the deployment and production process as possible. This can cause anxieties that operations people may be automated out of a job. However, what actually happens is that as lower-level elements become more automated, skilled people move up to solving more complex problems and as a result, demonstrating higher value.

Greater automation also requires greater collaboration between development and operations people to understand and interpret customer needs and deliver a better product. This, in turn, enables the whole team to broaden and deepen their skills and knowledge across both 'Dev' and 'Ops'.  The specialised knowledge of the Operations teams can be used to create jobs for the developers to run; this shifts the effort “left” earlier in the lifecycle and ensures the jobs are run multiple times before they are run for real in production.  This leaves more time for the Operations staff to start focusing on new capabilities that their specialised skills are required for, like self-healing systems.

DevOps at Optimation

At Optimation, we put the customer at the heart of everything we do, and we see DevOps as integral to this mission.  We have long embraced Agile principles and practices across our Software Development and Integration practice. Now, we are seeing our customers across Government, Finance and other sectors steadily moving into using DevOps practices, and a growing number of RFPs asking for agile services and continuous deployment. DevOps is a good fit for our culture of collaboration and high-performing teams and we are on a journey to embed it at all levels of our organisation. Over the coming months, we'll share more on our DevOps experience and what we learn along the way.

External reference links -