DEVOPSdigest

Given that a long time ago I wore two separate consulting hats — agile development and operational management — you can imagine my delight when some bright spark came up with the term DevOps. I've been spending the past couple of years looking at how to make DevOps real through best practices, supported through the use of supporting technologies running across development, through deployment and into operations.

The Missing Elements of Best Practice

Perhaps the most important lesson I have learned so far is how many elements of development best practice have been notable by their absence. Unfair, I hear you say! We have Kanbans and Scrums, continuous everything, shift-left security and end-to-end quality, infrastructure as code, feature flags and quality gates and fail fast and the list goes on. But still senior management struggles to keep in control of what is going on, and to know whether all the effort is delivering results.

In terms of making this happen meanwhile, many enterprises I come across are in some half-way house, looking to make the cultural changes they know they need to make wholesale, but seeing only pockets of success. With every business wanting to be a software business (in principle at least), the demand is there for a clear path which takes an organization from where it is to such an, altogether better place.

As an aside, I'm not one of those people who believes that DevOps is actually more DEVops, with developers holding the exclusive keys to the kingdom, and operations staff as mere serfs who will one day be automated into oblivion. Infrastructure is, and will continue to be, too complex for that. Having said this, I'm going to focus here on the Dev side of the equation, as there's plenty of scope to improve this.

In principle, the answer is clear: development teams need to get better at what they do. That's what many of those best practice notions are about, right?

Pretty much every time I've read about implementing such measures, I've heard that the best bet is to start with a key team and then grow it out to the broader organization, as if best practice can permeate many thousands of people through osmosis alone.

The alternative is to implement some kind of structured change program in which the organization as a whole increases its maturity. This model, derived from quality management best practice of the 1970s, suggests that putting the right processes in place will engender good practice by their very presence. If chaos is your problem, structure is your inevitable solution.

Can Maturity Models Help?

Structure cannot happen just like that, which is where maturity models come in. Get the basics right and build on them, until you are a master of your destiny.

If we go back to SEI terminology from 1986, we have 5 stages, from initial to repeatable, then defined, then managed, and finally, optimized. Each stage is an adjective, and process is the noun, implying that the most mature organizations will have the best, self-optimizing and constantly improving processes.

Fact: these levels do not reflect any organization that I know, and more importantly if I think back, they never did. Given that we've been at this for many decades now, we should be pretty mature by now, right? So, why is it that, when I speak to organizations, I find so many still linger in level 2, going on 3? In other words, while the model may appear coherent in principle, it has not been effective in practice. Perhaps that's why I've never much liked maturity models very much.

The underlying idea is that by understanding processes, you can control them — this model reflects a command-and-control mindset that doesn't sit too well with modern innovation practice. Throw in the phrase "business agility" and you can already see the flaw in this argument: the concept of an agile process is in itself an oxymoron.

So, should we all pack up and go home, allowing the entropy of the universe to take its course? Of course not. The answer lies in aligning practices with reality, rather than trying to corral reality into some theoretical ideal.

Go to Unpicking the Acronym: Value Stream Management - Part 2