Most companies have already initiated some kind of agile transformation since ‘customer-centricity’ and ‘startup mindset’ became buzzwords in the community. But the same organizations often tend to hit the brakes before taking a step further and delivering the product to the market at the same speed as it was developed. Instead, they release how they always have — by accumulating enormous scope and endlessly waiting for sign-off reports and testing results.
This is where DevOps culture might save the day.
What is DevOps culture?
DevOps culture is a set of principles that enables teams responsible for software development and operations to collaborate in a more efficient way and deliver high-quality deliverables faster. Patrick Debois, who coined the term “DevOps”, describes that DevOps culture can help “stop money wastage, deliver great software, and build systems that scale and last longer”.
Since DevOps is more about cultural adoption rather than technology, the shift has to first happen in the minds of those involved, so that it can then be reflected in the resulting operations and strategies. Gartner revealed that enterprises attempting to use DevOps without addressing the important cultural aspects will fail about 90 percent of the time. So, what behavior changes do you need to roll out to painlessly bridge the gap between IT and operations?
Here are five working principles you can start with.
5 DevOps principles for a successful transformation
1. Foster a collaborative environment
Companies aiming for DevOps culture transformation should treat the software they create as a product rather than a service, regardless of the business model. Benefits like the speed of delivery shouldn’t cancel out reliability and quality.
With this in mind, start with the change from inside the teams instead of pushing new rules from above. That said, executive buy-in is extremely important to keep the DevOps initiative going — your developers will need time to understand what they’re doing it for. Starting small and scaling up enables both parties to see the perspective of the other without feeling pressured to comply with forced guidelines.
For such a stimulating environment to prosper, you will have to establish a communication flow that will allow weekly and daily syncs to share ideas and brainstorm on issues together. This will contribute to a mutual mentoring dynamic and an understanding that operations problems are now development problems, too. When development and deployment processes merge in a single flow, it minimizes the chances of things going south all of a sudden.
2. Ally the incentives for developers and operations
The objectives for both dev and ops sides have to be common because this is where the core of the conflict lies. Simply announcing the culture shift without adjusting the objectives will have little or no effect. While dev teams are measured by the speed they can present new features, ops are expected to focus on uptime, and these performance metrics are not in the same category. Getting these teams on the same track is a tall order.
A pro tip here is to reward end user experience improvements and not only the progress itself. When goals become common, roles also shift from “I write code and pass it on to someone else to deploy it” to “I am responsible for the product from concept to grave.” Put simply, this means full accountability of everyone involved to eliminate inefficiencies in the final performance and quality. This change is big and scary for both developers and system administrators – the lines between positions in the team and responsibilities associated with them become blurry.
This is where the next issue arises: quality control is no longer as effective as the last frontier for newly developed features. Instead, control activities should be embedded in every stage of software delivery by default rather than testing everything afterward and dealing with all of the accumulated bottlenecks at once. This boils down to the cultural aspect of DevOps values — it requires every team member to possess a well-rounded set of skills, since each specialist is now a part of every stage of software development.
3. Minimize the cost of failure
The biggest difference between continuous delivery and the old-fashioned release culture is that the latter penalizes failure instead of welcoming it as a natural part of the process. DevOps practices is about reducing this fear of failure by moving forward in chunks – this is what frequent releases are for. Since the goal is to lower cost of failure, there is no point in dreading it – as they say, “if it hurts, do it more often.”
Break your deliverables into smaller chunks, and go as deep as your infrastructure allows you to. It may feel like a catch-22 at first, but if you let the experimentation environment thrive, it will eventually foster productive cross-team collaborations. Before you know it, each iteration will cost less – financially and psychologically – than the previous one, not to mention the learning climate that comes out of accepting failure.
As a result, your developers will treat mistakes as milestones in the software development quest, and not fixate on blaming someone. In the long run, there will be a shift from a limited developer mentality to an operation- and performance-driven one.
4. Automate what you can
With continuous delivery, there’s no time to waste. Releases are frequent, and automation is what keeps the cycle running. Automation also enables a lightning-fast user feedback loop, which comes in handy when you rapidly release new, highly anticipated features. But, this is not only about converting routine and time-consuming tasks into scripts, but also about ensuring a solid quality assurance control suite that is reliable and safe every time.
Think about automation as a way to reimagine service delivery. You transform your whole infrastructure into code for usability purposes, to set up and manage the entire environment with a script, without demanding manual configurations.
To sum up, machines are undeniably faster than humans when it comes to building software products. Several processes can be automated in the continuous integration (CI) and continuous delivery (CD) pipeline:
- Infrastructure provisioning
- Building new systems
- Software deployment
- Testing
5. Improve continuously
Since we’ve already broken down the mentality, fear of failure and objectives shifts, the improvement perspective is next in line to be challenged. The eagerness to make everything perfect is understandable – but in DevOps concepts, “good enough” is the stage where you stop fine-tuning the tiniest details and continue to iterate. In this culture, product teams shouldn’t be afraid to slip up or pursue multiple new opportunities, because they can make adjustments and rigorously test as often as they need to.
In fast-changing internal and external circumstances, like technology innovation and changes in legislation, business goals and consumer demands, end-to-end responsibility empowers you to adapt quickly. Consider the continuous improvement of your product as a funnel to get rid of process waste and optimize for speed and ease of delivery.
Finally, the continuation in the DevOps context is synonymous with patience. The organizational change will take time no matter what approach to the culture shift you choose. Just unify the T-shaped, cross-disciplinary expertise from both ends and get ready to yield the results – after conquering a certain uncompromising mindset, of course.
For more clarity on the subject, we asked a DevOps specialist for their valuable insight regarding the impact of a culture shift on teams.
Is moving to DevOps culture as difficult to get used to as business leaders often imagine?
"I would say that if you’re experienced enough in system administration, you may already consider yourself a DevOps engineer. There’s no drastic difference, or ‘before and after’ moments. It was quite the opposite for me. At some point, plain hardware management got boring, so I gladly evolved to more complicated, coding-related DevOps system administration.
As for developers, they still write code as they used to, but observe the process from a different angle. Since DevOps was first introduced back in 2009, new software products for optimizing the CI/CD pipeline have come out regularly, but the core principles have remained unchanged." — Andrey Litvin, DevOps engineer at Forte Group
FAQ
How can one define a DevOps mindset?
DevOps mentality can be put simply: software delivery success rests on a common cross-functional commitment, and there’s shared responsibility. The software won’t run without the code developers write, the fixes QA engineers suggest, and the systems operation specialists engineers build and maintain.
Which DevOps principle focuses on product and service thinking?
Almost any DevOps principle is outcome-oriented. The goal is to always continuously improve services and products rather than produce software on demand, optimize costs and resources, and think of user experience as a result.
What are some keys to achieving DevOps value?
The article above goes into far more detail, but the bottom line is — cut waste (work lean), get rid of the fear of failure and learn from it instead, automate as much as possible until it makes sense, and ensure that every voice counts in the process.
Do DevOps practices include coding?
They most definitely do. Although do not expect pure coding from DevOps career — it is a blend of system operations, development, testing, and many other things. The most important skill you’ll need is the ability to collaborate along with a profound understanding of software development practices.
What is the goal of DevOps?
Establishing a continuous delivery pipeline that brings predictable quality and valuable outcomes to the organization during frequent releases. All of this creates a safe environment for exploration and experiments.
