Moving to DevOps, what’s most important?

You’ve been appointed the DevOps champion in your organisation: congratulations. So, what’s the most important issue that you need to address?

It’s the technology – tools and the toolchain – right? Everybody knows that unless you get the right tools for the job, you’re never going to make things work. You need integration with your existing stack – though whether you go with tight or loose integration will be an interesting question – a support plan (vendor, 3rd party or internal), and a bug-tracking system to go with your source code management system. And that’s just the start.

No! Don’t be ridiculous: it’s clearly the process that’s most important. If the team doesn’t agree on how stand-ups are run, who participates, the frequency and length of the meetings, and how many people are required for a quorum, then you’ll never be able institute a consistent, repeatable working pattern.

In fact, although both the technology and the process are important, there’s a third component which is equally important, but typically even harder to get right: culture. Yup, it’s that touch-feely thing that we techies tend to struggle with[1].

Culture

I was visiting a medium-sized government institution a few months ago (not in the UK, as it happens), and we arrived a little early to meet the CEO and CTO. We were ushered into the CEO’s office and waited for a while as the two of them finished participating in the daily stand-up. They apologised for being a minute or two late, but far from being offended, I was impressed. Here was an organisation where the culture of participation was clearly infused all the way up to the top.

Not that culture can be imposed from the top – nor can you rely on it percolating up from the bottom[3] – but these two C-level execs were not only modelling the behaviour they expected from the rest of their team, but also seemed, from the brief discussion we had about the process afterwards, to be truly invested in it. If you can get management to buy into the process – and to be seen to buy in – you are at least likely to have problems with other groups finding plausible excuses to keep their distance and get away with it.

So let’s say that management believes that you should give DevOps a go. Where do you start?

Developers, tick?[5]

Developers may well be your easiest target group. Developers are often keen to try new things, and to find ways to move things along faster, so they are often the group that can be expected to adopt new technologies and methodologies. DevOps has arguably been mainly driven by the development community. But you shouldn’t assume that all developers will be keen to embrace this change. For some, the way things have always been done – your Rick Parfitts of dev, if you will[7] – is fine. Finding ways to help them work efficiently in the new world is part of your job, not just theirs. If you have superstar developers who aren’t happy with change, you risk alienating them and losing them if you try to force them into your brave new world. What’s worse, if they dig their heels in, you risk the adoption of your DevSecOps vision being compromised when they explain to their managers that things aren’t going to change if it makes their lives more difficult and reduces their productivity.

Maybe you’re not going to be able to move all the systems and people to DevOps immediately. Maybe you’re going to need to choose which apps start with, and who will be your first DevOps champions. Maybe it’s time to move slowly.

Not maybe: definitely

No – I lied. You’re definitely going to need to move slowly. Trying to change everything at once is a recipe for disaster.

This goes for all elements of the change – which people to choose, which technologies to choose, which applications to choose, which user base to choose, which use cases to choose – bar one. For all of those elements, if you try to move everything in one go, you will fail. You’ll fail for a number of reasons. You’ll fail for reasons I can’t imagine, and, more importantly, for reasons you can’t imagine, but some of the reasons will include:

people – most people – don’t like change;

technologies don’t like change (you can’t just switch and expect everything to work still);

applications don’t like change (things worked before, or at least failed in known ways: you want to change everything in one go? Well, they’ll all fail in new and exciting[9] ways;

users don’t like change;

use cases don’t like change.

The one exception

You noticed that, above, I wrote “bar one”, when discussing which elements you shouldn’t choose to change all in one go? Well done.

What’s that exception? It’s the initial team. When you choose your initial application to change, and you’re thinking about choosing the team to make that change, select the members carefully, and select a complete set. This is important. If you choose just developers, just test folks, or just security folks, or just ops folks, or just management, then you won’t actually have proved anything at all. If you leave out one functional group from your list, you won’t actually have proved anything at all. Well, you might have proved to a small section of your community that it kind of works, but you’ll have missed out on a trick. And that trick is that if you choose keen people from across your functional groups, it’s much harder to fail.

Say that your first attempt goes brilliantly. How are you going to convince other people to replicate your success and adopt DevOps? Well, the company newsletter, of course. And that will convince how many people, exactly? Yes, that number[12]. If, on the other hand, you have team members from across the functional parts or the organisation, then when you succeed, they’ll tell their colleagues, and you’ll get more buy-in next time.

If, conversely, it fails, well, if you’ve chosen your team wisely, and they’re all enthusiastic, and know that “fail often, fail fast” is good, then they’ll be ready to go again.

So you need to choose enthusiasts from across your functional groups. They can work on the technologies and the process, and once that’s working, it’s the people who will create that cultural change. You can just sit back and enjoy. Until the next crisis, of course.

1 – OK, you’re right. It should be “with which we techies tend to struggle”[2]

2 – you thought I was going to qualify that bit about techies struggling with touchy-feely stuff, didn’t you? Read it again: I put “tend to”. That’s the best you’re getting.

3 – is percolating a bottom-up process? I don’t drink coffee[4], so I wouldn’t know.

4 – do people even use percolators to make coffee anymore? Feel free to let me know in the comments. I may pretend interest if you’re lucky.

5 – for US readers (and some other countries, maybe?), please substitute “tick” for “check” here[6].

9 – for people who say, “but I love excitement”, trying being on call at 2am on a Sunday morning at end of quarter when your Chief Financial Officer calls you up to ask why all of last month’s sales figures have been corrupted with the letters “DEADBEEF”[10].

10 – for people not in the know, this is a string often used by techies as test data because a) it’s non-numerical; b) it’s numerical (in hexadecimal); c) it’s easy to search for in debug files and d) it’s funny[11].