In the last post, I described the ways in which DevOps and Continuous Integration/Continuous Delivery (CD/CI) enable Agile development, as well as highlighted some of the many benefits of building a DevOps organization. Here, I’ll take the conversation a step further and focus on what’s required to build a successful DevOps organization once you recognize and accept that DevOps is right for your organization.
In short, how can an organization look at the product development process as a whole and facilitate the product team’s ability to get better products out the door faster?
It starts with cultural change.
DevOps Requires a Cultural Shift
Before an organization heads down the DevOps path, that organization needs to do some soul searching. You may be wondering what I mean by a cultural change within an organization and what that change actually looks like. Let me explain.
From the RO perspective, a DevOps implementation involves a dramatic cultural shift, including a willingness to adopt practices that facilitate the performance of lean product development. These practices reinforce automated software delivery and infrastructure processes from top to bottom and encourage collaboration among engineers, operations staff, and the entire product team. The processes and supporting infrastructure serve the entire product organization, and the entire organization needs to get behind those processes and infrastructure in order for them to work.
This is no small task. According to Gartner, “[B]y 2018, 90 percent of [infrastructure and operations] organizations attempting to use DevOps without specifically addressing their cultural foundations will fail.”
Why will these DevOps implementations fail? First and foremost, because some organizations haven’t embraced lean product design and don’t understand the benefits of DevOps. DevOps may seem confusing to some members of your team. They may not love the inefficiencies of their current processes, but those processes are the devil they know. They may also be confused about the impact change will have on how they work and may not understand the ways in which their contributions will matter in the newly transformed organization. Instituting new development practices takes hard work, and team-wide buy-in won’t happen overnight.
Change is needed. That much may be clear to you, if not to everyone else on your team. What may be less clear is that this change needs to come from within. Your DevOps partner can make arguments all day long about why change needs to occur and why DevOps is simply the right thing to do, but your DevOps partner can’t institute those changes for you. (You chose your DevOps partner for their platform expertise, not because they’re organizational change management specialists.) In short, your organization either buys into the benefits or it doesn’t.
With a Cultural Shift Come New Possibilities – and New Practices
If you’re struggling to introduce a cultural shift at your organization, you’re in good company. To make the shift easier, think big picture. Consider how development and operations teams might work together to make software more operable from a feature, data/metrics collection, CPU, memory, disk or data storage perspective. Then begin the conversation. Help the members of your team see why collaboration, collective insight, intentional design, and automation can enable the rapid and replicable production of more reliable code.
Then take the next step. Maybe you want marketing to be able to weigh in on whether a feature goes live – or on what features are needed in the first place. Or maybe you want QA to be able to participate in the design of a robust feature or want to empower the development team to create a more resilient feature. Or maybe you want the test team to perform more exploratory testing and experiment with making features fail in interesting and ultimately useful ways.
Share your ambition with the product team to help them understand why these kinds of involvement matter – to themselves, to the overall team’s success and to the company’s bottom line.
Your DevOps platform should allow your developers and operations staff to have these conversations more frequently and more successfully. Your DevOps partner may handle operations for you, but that doesn’t bypass the need for an open dialogue throughout the product team. A managed hosting solution may give you someone to yell at if something goes wrong, but it doesn’t give you a better window into product functionality or enable rapid-fire progress. A solution involving completely outsourced operations may take operations tasks off your plate, but it doesn’t foster the innovation and productivity of true DevOps collaboration.
In the DevOps world, product developers are responsible for running their apps in production. Developers are – and absolutely need to be – involved in the process. Why? Because the person generally best suited to fix a production failure is the same person who wrote the failing code in the first place. Involving developers in a 24/7 pager rotation, for example, properly incentivizes them to create operable features that can be diagnosed easily.
And that brings me to the Idea of Incentives
Your DevOps partner can’t fix an organizational culture where incentive alignment is broken. When developers are paid to fix bugs, developers are incentivized to create bugs. When QA testers are paid to find bugs, QA testers are incentivized to make everything seem like a bug. (You get the picture.)
Incentive misalignment reinforces silos, and a highly siloed model isn’t the right fit for DevOps. You can implement any number of DevOps tools intended to initiate change and improve operations, but incentivizing people the wrong way leads to inefficiency and unproductive business outcomes. No matter what.
Incentivizing the right behavior is critical. And those incentives must be instituted from within your organization. Said another way, good behavior and DevOps buy-in start at home.
In the next blog, I’ll review some thoughts – the last in this series – about how to tell if your organization is truly ready for a DevOps transformation.