DevOps needs a new name

DevOps isn’t Dev-Ops, Dev & Ops or Development and Operations. It is one team. Not many people seem to know that.

If you’re building a new software capability like I am, you have to make a few decisions. Some of those may well define a ‘great place to build real products’.

I made one a while back; If we are a small, on-shore, high end consultancy we’re going to need a well picked set of people who are ‘engineers’ at the core and think about product from a Functional, Performance, Security, Usability and Stability point of view; All at the same time.

This is where DevOps comes in. If you care about your product in Production, with real users, why not create one team that manages a process from idea, through backlog, development and test, and on to a live service? Why, as a developer, would you want to be hidden away from ‘users’ allowing ‘the Ops people’ to get all the glory of user satisfaction (and *perhaps* some grief when they have to support troublesome systems from code thrown over the ITIL-transition-wall).

Over the last decade I have been doing some recruitment. Developers, developers-in-test, business analysts, system engineers, tech project managers, and all the others…. Since I started building the software team at E Fundamentals one key question I ask is “what does DevOps mean to you?” The answer is never consistent, and never accurate within the definition of the modern paradigm.

I find myself saying it really quickly — devops — so there is no pause between dev and ops -but I will still regularly get an answer that defines the Dev bit, and then the Ops bit. I also get some nose turning. Recently I get the impression that if you advertise for ‘DevOps’ as part of the role or the organisation “people won’t apply”. I think this makes it the ideal test. If you shy away from being part of building a Production ‘system’ — the platform build, the system engineering, the automation of test and deployment, the components, libraries, custom code and the monitoring/alerting, and don’t want to be held to account for quality, look away now. “Jog on”, as they say.

If you and the organisation passes this test, what does mean in practice?

1. The whole team fights to make sure product deployments are one-click automation cycles and that *anyone* can make the deployment to live
2. We push for releases as often as possible — “I want my feature in live, I want people to use it”
3. The whole team reacts to Production issues — it might be one or two that do something about it-but everyone sees, hears and cares
4. Backlog stories that state functional requirements have acceptance criteria that include monitoring, alerting and backup, as well as changes to the deployment automation and test harnesses where applicable

This list is not exhaustive, but gives a flavour of what we are creating here, and how you can start your own transition — or test the one you have. Just saying “we practice DevOps here”, probably isn’t enough.

It would great if I could now announce a new name for ‘DevOps’ that encompasses the desire to match smaller teams in lean development cycles with a very strong sense of a single team delivering digital products. I haven’t quite got there yet — I offer the challenge, find me a better name please.

I’ll call it ‘one-team’ for now.