Why DevOps is (still) a work in progress

Pope writes as follows…

DevOps was supposed to fix everything, right? Okay well maybe not everything, but the coming together of Dev (developers) and Ops (operations) under the umbrella that is DevOps was meant to give us a new way of building software with greater team proximity that would ultimately result in better end products for the user.

Don’t get me wrong, DevOps has done well. But if there is a ‘last mile’ in DevOps that we’ve yet to travel, it actually comes back to people and the way we approach workflows.

Point of paradox

Effective DevOps is still all about technology, obviously. But truly effective DevOps is more about people, process and culture than it is about any single vendor’s fancy DevOps package. I would go so far as to say that most DevOps programmes fail because, paradoxically, they’re too focused on the technology.

I was speaking to a particular company this month who told me how it has embraced Agile development practices through DevOps. The organisation had managed to get itself to two releases per year and was delighted with its DevOps structure, Kanban boards and brown-bagged sandwich team lunches.

You did read that right; I said two releases per year.

I think I said something along the lines of: that’s not Agile, that’s ‘tragile’ (as in tragic), which they didn’t particularly appreciate.

The point is, talking up DevOps and buying in a hundredweight of multi-coloured Post-It Notes is not enough. Getting past two releases a year is only achievable when you show people the value of working differently through a more orchestrated approach.

Intelligent automation appreciation

When employees on both sides of the DevOps coin start to understand what tasks they need to focus on, then they can start to understand what they need to worry about more, and what they need to worry about less.

DevOps allows us to gain huge competitive advantage through automated code functions that happen throughout the software development lifecycle, but automation only happens if people know that the automation advantage is there… otherwise they might carry out the process manually.

This is why I say that DevOps is still a work in progress. When people start to understand where they are and what their place is in the workflow, then they’re more readily freed up to start solving real business problems and creating truly new software functionality. Well executed DevOps practices hinge around a core appreciation of this reality and require less people, because systems run more efficiently.

Cloud’s democratic pervasiveness

Although there has been a huge weight of industry discussion in the decade or so that we’ve had DevOps in its current form, we did learn many of the core change management lessons being tabled here way back in the age of the mainframe. The difference now is that the web is ubiquitous and cloud is democratically pervasive. This is generally a good thing, but it does bring with it a new responsibility.

What I mean is that anybody and everybody can deploy to the cloud and this makes things more complicated at the surface level. In the distributed computing world of cloud, well-orchestrated DevOps with intelligent workflow management has to be in place, or we risk flying blind.

It’s a bit like the over-engineering that old school drivers complain about when they look at modern car engines. You used to be able to get your hands dirty and tinker with the mechanics, but you can’t do that anymore. If we’re going to drive software forward now on a more sophisticated internal combustion engine, then we need to have protocols and processing in place to be able to deal with that level of higher engineering.

The last mile of DevOps

If it is lacking anything, DevOps is lacking tooling for insight into the whole development and operations process. It won’t be easy. Developers hate process. They’d rather be freebasing and creating some wild new ideas that buck convention and play around with abstract design ideas that might create the next Twitter.

Like I said at the start, when it comes to DevOps, people are too focused on technology and not focused enough on people and systems of work as well as human aspirations and requirements.

This is the last mile that DevOps has yet to travel. This is the route to being able to gather code artefacts and comply with all the required levels of governance and auditing. This is the way we can contain, corral and coalesce all the creativity that great DevOps teams have the potential to deliver.

Next time somebody tries to sell you a DevOps platform, dashboard or toolset, do me a favour will you, please? Don’t ask them what the software does, how powerful it is or how well it integrates. Ask them where the people fit in. If you can do that, then I’ll treat you to an all-you-can-eat order of Post-It notes and a side of fries.

Editorial disclosure: Adrian Bridgwater has worked on corporate content projects with ServiceNow.