Four practical tips to fostering a DevOps culture in your organization.
This is Part Two in a four-part series. In Part One, I focused on the critical first step of defining DevOps with a purpose by thinking about DevOps in the context of your organization’s applications.
Today, we find more and more businesses putting pressure on IT to move faster, and, if their IT department struggles to keep up, they are often willing to “go around them” and invest in a cloud or other third-party solution on their own to get what they want, when they want it (aka “shadow IT”). What the business often lacks, however, is a full understanding of the many downstream implications that come with speeding the roll out of new services such as security assessments, integrations to legacy systems, the ongoing cost to administer the solution and take on support for it, etc. It’s true that Ops teams want to control the reliability and stability of software deployments and that can often slow things down, but they do this because that’s what they are paid to do: to deliver stable, reliable, and high-performing services.
This conflict between the business’ desire for speed and Ops’ charter for security, reliability, and performance, has been brewing for several years and it’s time for some introspection and a few tips on how we can make things better. Ultimately, progress is all about culture, and that’s why defining DevOps with a purpose must include focusing on your organization’s IT culture.
Tip #1: Recognize the cultural challenges between the business, Dev and Ops
Because Development sits closer to the business in the IT value chain, there’s usually less conflict between the business’ desire to move fast and Development. That isn’t to say Dev managers aren’t sometimes frustrated by how fast the business wants things given the resources available to them, but they usually are motivated and compensated to move in sync with how fast the business wants to move.
The first tip is to take a step back and benchmark your current culture for both Dev and Ops, because only then will you be able to understand how DevOps may impact those cultures. With Dev, ask yourself, for each line of business “Are we still doing waterfall software development with one release every year or eighteen months, or have we adopted agile methodologies that enable us to deliver multiple releases throughout the year?” Based on your answers, then ask, “Is that in line with what the business wants today? Is that inline with what we think makes the most sense or are there opportunities we could bring to the business if we adopted agile more broadly?” Finally, “what would be the value to the business and cultural impact of adopting DevOps principles for continuous integration of new software development?”
Next, ask yourself, “How focused is our Ops team on stability, reliability and clamping down on change vs. accepting (and even desiring) change? And how does this vary by line of business or application area?” (see Part 1 of this series for why that matters) If you have a risk-averse Ops culture that’s supporting a fragile infrastructure or many legacy technologies, then you may need to tackle some of those challenges first in order to help your DevOps culture evolve. I also suggest looking at your Ops culture through a compliance lens. Ask yourself, “Are we in a heavily-regulated industry that has created its own cultural challenges in terms of change approvals and auditing that we need to take into account?” Finally, what would be the value to the business and the cultural impact of adopting DevOps principles for continuous delivery of new releases?”
One of the hallmarks of DevOps is the ability to develop smaller pieces of incremental functionality, deploy them faster (perhaps even a few times a day), and quickly roll things back if there’s an issue. This is a big leap for many IT cultures on both the Dev and Ops side so understanding where your culture is today is a critical first step.
Tip #2: Think about how you view work
Do you view work as tasks done by individual teams or in an end-to-end fashion (e.g. from raw materials to finished goods and customer delivery)? DevOps transformation requires focusing on work in an end-to-end manner. Your goal should be to identify where your IT organization’s bottlenecks are, with the intent of reducing pressure at those bottlenecks to increase end-to-end flow and, therefore, output that benefits the business.
In The Phoenix Project, the bestselling IT novel (yes, indeed an IT novel) co-authored by Gene Kim, Kevin Behr and George Spafford, the character of Brent Geller in the Ops team is an obvious bottleneck. He understands his company’s IT environment better than anyone and is consumed with both solving high-profile outages and deploying new application releases, the result is that he’s constantly putting out fires and unable to get new software released that’s desperately needed by the business. The book offers a wealth of perspective on how to embrace DevOps principles and what that means for your culture. I highly recommend it. You will likely see quite a bit of your organization in the story, I know it matched my experiences in IT very well.
Back to Top #2, ask yourself, “Is my organization optimized around end-to-end flow or are we optimizing just at the individual workstations?” If it’s the latter, then you are probably stacking up work somewhere at one or more bottlenecks and should address those first. For example, a development project isn’t done until the code is tested and deployed. So incentivizing developers to finish code without knowing when and how it will get deployed is just going to create more work in process stacking up in your IT factory. It’s just like on an automotive line where you might see cars with shiny paint, brand new tires and cutting edge technical design, but if the cars have no seats they simply won’t be shippable.
You might also be saddled with a lot ‘technical debt’ – where dollars and resources are tied up maintaining existing applications and infrastructure. It may be necessary for you to focus at first on reducing technical debt in order to reduce those as bottlenecks on your support and deployment teams. Ask yourself, “What technical debt do we have and who can be charged with prioritizing and reducing it?” Treat it just like credit cards and look to reduce the ‘high interest’ debt first.
Tip #3: Incentivize your people
Don’t assume people will change for the “greater good” – proactively incentivize them to do so.
If you want to change your culture and create one that’s more agile – if you want to optimize for flow versus workstations then you should incentivize to initiate the cultural change you seek. Old habits are hard to break even when we want to do things differently. As executives we have the tendency to appeal to a higher business purpose and assume the folks contributing on the front lines share the same passion for the company’s success. Often they intellectually understand these goals, but you should seek to make the change relevant to how it will improve their jobs as developers, QA team members, sys admins, and architects not just how it impacts C-level objectives.
For example, Ops folks usually take particular pride in their indispensability, but to be indispensable they have to compromise family time, working late and on weekends to push out a big high-risk deployment. They may crave the attention and recognition for such ‘extra effort’, but at the same time they are putting more pressure on themselves and more risk on the business.
As mentioned previously, the move toward a more agile IT means deploying with far greater frequency, and that can actually help you operate with less stress and risk. Errors and fixes are likely smaller in effort, and you will be able to roll back hick-ups much faster. Sure your folks may need to stay late occasionally, but they can do their work more often during typical working hours, reclaim their weekends and have significantly less stress and pressure than via traditional large-scale rollouts where expectations are high and so is the risk of failure, re-work, and long days. Plus, with DevOps you are actually delivering on business requirements faster – instead of deploying what was needed months ago.
Tip #4: Make it personal: everyone is different.
Related to Tip #3, realizing that everyone is inherently different is critical to incentivizing and empowering your IT team to transform. In most IT organizations, the responsibility is on the first line manager to know their people, understand what makes them tick and channel the right talents and motivations. Some may be seeing a move to DevOps as the ideal resume enhancement opportunity. Some may feel intimidation because they are innately risk averse. Still others may not be sure what to think especially if you have one team doing DevOps while they remain on a separate team doing things “the old way”. What’s important for managers is not to stop at how to make DevOps relevant for a role, but to consider the specific individual. Ask yourself, “How will each of my team members react to this cultural change, and how can I tap into their natural motivations to make them enablers of the change not resistors?”
From what I’ve seen, there also is a generational aspect to DevOps cultural transofrmation. Younger employees who don’t know a world without mobile phones and grew up on social media are likely more comfortable with agile, small release deployments. Those with more experience are also more likely to think about the reasons why DevOps ‘can’t work’ and it will be key for first-line managers to engage them, listen to their concerns, and work to address them in a way that benefits the organization and realizes the wisdom of their experience.
The bottom line for Tip #4 is that if you make it personal you will build trust and that will help you to drive transformation in your organization faster. Perhaps even consider establishing a ‘Take a Developer or Ops Team Member to Lunch Day’. By working to understand each other’s worlds, challenges, pressures and goals you can unleash a swifter cultural change within your organization.
In Part 3 of this series I’m going to tackle tool investments and how they can help you achieve DevOps With a Purpose (or stand in the way of it).