5 Definitions of DevOps, or, ¯\_(ツ)_/¯

DevOpsDays Amsterdam - Thursday June 25th

I’ve tracked at least three different definitions of DevOps since the days of “agile infrastructure”:

  1. Using Puppet and Chef (and then Ansible and Chef) to replace Opsware and BladeLogic.
  2. Full stack engineers to setup EC2, load-balancers, and other Morlock shit.
  3. Full stack engineers are bad, but sort of the same thing. Also, you can’t have a DevOps “group” or title. But, you know, someone should do all that automation.
  4. Putting all the people on one team, having them focus on a product, and establishing a culture of caring and learning.
  5. SRE is not DevOps.

So…actually five. Maybe some of them just being footnotes on the evolving concept. (And, if you, dear reader, feel these are wrong, then let’s compromise and make the list six.)

All of them evolved around bringing down The Wall of Confusion, allowing “developers” to deploy their software to production more frequently, weekly, if not daily. And, of course, making sure production stays up. (You’re supposed to call that “resiliency” and instead of SLAs use SLOs and some other newly named metrics that answer the question “IS MY SHIT WORKING?” Whatever you do, just don’t say “uptime,” or you’re in for it and will be relegated to running the AS/400’s.)

I used to snide that the developers seemed to have been yanked out of DevOps, sometime around 2014 and 2015. All the talks I saw were, basically, operations talks. I haven’t really checked in on DevOps conference talks recently, but at the time, I don’t think there was much application development stuff. (I’m not sure if there ever was?)

None of this means that DevOps is not a thing. Not at all. It just means that the enterprise finds its own use for things. It also means there’s still weekly write-ups of what DevOps is – you know, those ones that are always lists of ideas, things you’re getting wrong, and how to start.

Autonomous product teams

This kind of thing is happening all the time

Nowadays, I try to stick to that forth one: you want to setup autonomous teams that have all the skills and responsibility/authority/tools needed to “own” the software being specified, designed, developed, and run. This means you have to, basically, remove-by-automating all the operations stuff it takes to stand-up environments, deploy things, and do all that “day 2” stuff.

(HEY! HEY! WANT TO BUY SOME ENTERPRISE SOFTWARE?!)

Now, I think this product-centric notion of DevOps is, well, kind of an over-extension of the term “DevOps.” But since SRE has sucked out the “ops” part (but, remember, dear reader, don’t commit the embarrassing act of saying SRE is DevOps – no, no, you’d never do that, right? SO SHAMEFUL! (SRE is totally different – no overlap or similar goals shared between them at all. I mean, they have separate groups, silos! COME ON!)), slicing “DevOps” back to just “Dev,” but with a product-not-project focus isn’t too shabby.

Anyhow. I came across a good overview of this product notion of DevOps, all the way back from 2016, while re-reading Schwartz’s evergreen excellent The Art of Business Value:

Agile approaches attempt to bring together developers and the business in an atmosphere of mutual respect and joint contribution. Until now, however, the focus has been on users of the software, product visionaries, and developers. Recent developments in the Agile world—notably DevOps—have broadened this idea of respect and inclusion to encompass Operations and Security. The DevOps model, in other words, looks to break down the silos that have resulted from technical specialization over the last few decades. But the DevOps spirit goes further, looking to eliminate the conflicting incentives of organizational silos and the inhumane behaviors that can result from those conflicting incentives.

 

Perhaps we can take this idea even further still. There is no reason why the DevOps team’s responsibility needs to stop at the border of what used to be considered IT. The team is part of a broader enterprise, whose collective knowledge, skills, and judgment need to be part of the value creation process.

Look a’ that guy! Business Value just effortlessly jets out of his pores like a peripatetic thought-monarch!

This is from an executives perspective, but it drives home the point we’re always trying to get to with software: doing whatever it takes to figure out, create, and give users features that are actually useful to them. Somewhere beyond that, if you’re lucky, it’ll help out “the business.” Also, it should implement The Unspoken User Story: user would like software to actually work.

Link: The State of Agile Software in 2018

The third thing that I want to stress is the importance of getting rid of software projects as a notion. Instead we want to switch to a product-oriented view of the world where instead of projects that you spin up, run for a while and then stop; you instead say, “Let’s focus on things that are much more long-lasting and organize a product team around that.” Another way of thinking about it is: what are the business capabilities that your organization has, and then organize the teams around those. These business capabilities will be long-lasting and will necessarily mean combining together technical people and the people who are on the business side of things into the same team.
Original source: The State of Agile Software in 2018

Link: Project vs. product management, in government

Good discussion of doing product management instead of project management. Also, discussion of user metrics to track design and usability:

“Defining success metrics helps you focus on what’s important in your product and how well it solves the problems you’ve identified. Defining key steps the user must take is also important in order to shine a spotlight on where in the process users are failing. With this data, you can conduct further in-person research to understand why they are failing and devise an even better solution.”
Original source: Project vs. product management, in government

Link: Project management vs. product management

‘That discussion starts with a very concise and useful distinction between project management (the world the government knows) and product management (the world it doesn’t). Project management, they write, is “focused on managing to a plan” — such as managing schedule, budget, risk, policy compliance and then reporting status to stakeholders. “Success for a project manager is delivering a defined scope of work on-time and on-budget,” Johnston and O’Connor note. Product management, meanwhile, “is focused on delivering a product a user wants or needs.” Success for a product manager “is delivering a product that users love — and use to complete tasks (or in the private sector — a product customers will pay for).”’
Original source: Project management vs. product management

Link: Think in Products, Not Projects

“In a high level, projects are local optimization efforts. We get a group of people who create new (or improve existing) functionality for our customers and then we pass that onto a team that has no idea why the change was made and how this change was solutioned/implemented. Very often, the quality is low and this Maintenance team needs to deal with the issues. This creates a culture of tolerating low quality, accepting that maintenance/operation teams will deal with problems created by delivery teams, not allowing delivery teams to learn from their mistakes and hence keep repeating them, allow budgets to be set without proper data, treat people like easy-to-replace objects, and so on. This culture is ok with low expectations and tends to increase debt in many aspects like technical, product, talent, innovation, etc. As such, these organizations often run in reactive mode and are constantly catching up with what the competition has brought to the market. Changes are expensive and take too long to get in the hands of the customers.”

Original source: Think in Products, Not Projects

Making new products out of nonconsumption

“Too often, organizations are myopic. They only look for growth in the customer base they already serve. But by looking for nonconsumers and exploring what they are trying to accomplish — rather than focusing on their personal characteristics, purchasing patterns, or product preferences — organizations can discover the potential for new growth.”

Source: The Power of Designing Products for Customers You Don’t Have Yet