It's been said that DevOps isn't a set of rules or processes or a tool you can buy. DevOps is a culture.
I agree.
But while I think that's true, but it's not very useful as a way of guiding an organisation.
Changing Culture
If you've worked somewhere where a culture change has been pushed from upper management, you'd know how poorly that strategy works. I remember being at team meeting where an upper manager informed us that "we [had] an agile culture now". Which was great, but to nobody's surprise that direction wasn't quite enough. It turned out they still wanted a full project timeline up-front and an optimistic Gantt chart.
Of course, it's important to get management buy-in for anything that will change the day-to-day operation of a team. But management buy-in for a buzzword is very different if it doesn't come with support for doing things differently.
"We're a DevOps Company Now"
Last week, I spoke about Brownfields DevOps at NDC London. It was a talk on how to work with existing legacy or "brownfields" software to make it easier and faster to safely make changes, deploy those changes, and measure them in production.
I asked the audience, partly tongue-in-cheek, whether they'd ever been told to change their culture. For example, had anyone been told they were to "do DevOps now"? There was some awkward laughter that spoke volumes.
The main problem comes when the buzzword is identified as something the business must have, while there's little support for what that buzzword actually means.
Bottom-up
I'm a firm believer that a DevOps culture can only come from the teams on the ground. The people working in dev, operations, testing, and support.
Management support for changing work practices is important, but those changes have to take place because the team wants them to take place and makes them happen, sometimes despite what the business asks for. As the saying goes, it's easier to ask forgiveness than permission.
What can you do?
As someone in dev, operations, or any other technical team, you have more control than you think.
- Does the architecture of your application support regular change without constant regression testing?
- Can you consistently and safely deploy to production or is it a nightmare every time you release?
- At deploy time, how dependent are you on the state of your production environment?
- Do you have metrics on whether the features you just released are being used?
All of these questions can be answered, and problems solved, by technical teams. And aside from the time needed to make changes (ask forgiveness, not permission), they don't require a management directive.
Back to the Culture
Once you start thinking of ways to improve the agility of your software and process, the culture change will happen.
A culture change happens as a side-effect of becoming more efficient and seeing success. It feeds on itself - every change you make that improves productivity and reduces frustration encourages you to make the next change, then the next. Before you know it, improving your process becomes a primary consideration whenever you do any kind of work - and that's a DevOps culture.
Next post
In my next post I'll expand on some specific things you can do as developers to move in the right direction. Whether you're doing a File | New Project, or working on "brownfields" software, there are practical steps you can take to start "doing DevOps".