Zombie Ostriches vs. DevOps

Early in my career, I thought that best practices and standards were a good thing to understand and align with.

I stumbled on a few of them as I bounced through my early jobs and projects - SSADM, ASAP, ITIL, PRINCE2, CMMI and maybe a few others I’ve forgotten.

They seemed useful for a while because they provided a framework to describe what I was doing. A kind of non-religious bible with commandments that told us what good looked like. And they provided a ‘common language’ that enabled people to connect.

Words with definitions designed to eliminate vagueness - incidents, problems, known errors, products, gate-reviews and stakeholders.

Some of these terms were semi-useful. But some seemed to be designed to ensure that even your most vacant colleagues could keep up during a project kick off meeting - I mean having a definition for ‘document’. Really?

At a certain point - when I was working for PricewaterhouseCoopers - I had a dawning realization.

Best practices aren’t the best.

They’re just somebody’s - or more likely - some (professional) body’s - hallucination of “best".

Which begs the question “who says they know best?"

ITIL for example was designed by a load of 40-50 year old public sector people who were involved in running UK central government systems.

Experts I’m sure.

I actually met some of them early in my career and it was like being held captive in a deja-vu torture chamber for what felt like three years. But it was only four short meetings - with my head in my hands.

PRINCE is the same - how anybody can advocate following the same project management methodology as the UK Government - hardly a sterling example of successful IT project delivery over the last few decades - is totally beyond comprehension.

But the big problem with ‘best practices’ is not that they’re made up by people who aren’t involved in the best practices. No, the big problem is that they’re in no way practical.

Ten years ago, I started using the term Practically Best instead of Best Practices. And built a successful consulting career advising forward-thinking companies on what worked Best in the Practical world. This involved asking questions.

Important ones like “what are you trying to achieve here - strategically as a business…?” and then doing some hard thinking to help them work out a plan of action, or help them design target operating models to support their goal.

It involved simple things like ‘branding’ their IT capability properly. How good do you think people feel who work for the 2nd Line Desktop Support Team? Not as good as the people who wore their underpants on the outside in the Usability Response Squad I can tell you. And the URS superheroes couldn’t forget their purpose in life either.

It even involved delivering Practically Best advice to one of the worlds biggest consumer goods companies on major incident management dressed in a chicken suit. Without a head.

Best practices stop people thinking. And they stop people from imagining that there’s a better. Because Best is as good as it gets.

Well, it’s not. And I hate Best Practices.

But the even bigger problem with these quasi-religious best practices like ITIL, PRINCE2, CMMI is that they spawn quasi-religious best practice fundamentalists. People who say things like.

ITIL says that you must have a Known Error for every Major Incident within 5 days of service restoration….

or

Yes but PRINCE2 states that tasks must be product based - we need to focus on deliverables…

or

If we’re going to define a service, ITIL says we should start with an SLA...

First off, inanimate entities (like methodologies) can’t say or state things. They are incapable of having an opinion, less so vocalize it.

The kind of people who spout this stuff are dangerous and should be ejected from any modern IT delivery organization that wants to do what it’s supposed to do - help the business operate and deliver competitive advantage.

In a way, all of the above is why I love DevOps.

It isn’t a set of ‘best practices’.

It’s a movement. A philosophy that supports a tangible business goal.

And because it’s hard to define as a ‘process’ or with ‘rules' or by a 'common language’ - you’ll find that the ordinary people in your IT organization don’t get it. Instead, they dismiss it as futuristic nonsense. Something from the Jetsons that big companies with massive consumer volume, always on operations - like Netflix, Amazon, eBay and Facebook use. But which isn’t ‘right’ for them.

Well good luck with that.

Because if I had to place a bet on the success of a business who embraces the DevOps philosophy vs. a business with a walking dead population of grey-skinned ‘best practice’ zombie ostriches, with their empty heads in the sand, I’d bet everything I have on the former. And I'd pity the latter.

Exciting times for the brave.