Why Business Value eats DevOps for breakfast

It’s 2020 and my new years resolution is to keep a list of words that deserve to be on the naughty list:

• DevOps
• Agile
• Requirements

It’s not that these words are inherently bad — but my industry has twisted, abused and polluted them leaving behind a trail of over-engineered solutions and misguided teams.

For an in-depth look at “how to do the DevOps” see my post One DevOps Please which talks about how to do transformation and discusses the unicorns that are “DevOps teams”.

First, a little warm up…

I’d like to interrupt this blog to do a warm up exercise. Sorry-not-sorry for anyone I’m about to offend.

Repeat after me:

I am not a DevOps Engineer

Let’s try another one:

I don’t belong to a DevOps team, because I only work with things that are real

One more:

Doing standups every day at 9am doesn’t make me agile

You say these every day along with burpees, planking or whatever your daily routine is. I promise you they’re good for your health.

Why — should I care?

You might have heard the following:

We’ve always done it this way

If “why” is the super hero of this story, then this phrase is the villain.

Like many youngsters I spent most of my childhood asking “why”. Ironically I’m sure my parents asked themselves “why” they had to have one more kid as I pestered them with endless questions about science, the universe, or whatever else was on my mind.

My questions didn’t stop at childhood. I’ve always had an obsessively curious mind and a determination to understand everything inside-out. I did it with helpdesk support, then when I stepped into development, and again when I learnt about cloud and automation.

Helpdesk me:

Why do clients always call with the same MSSQL replication errors

Developer me:

Why does my code work differently in production

“DevOps” me:

Why doesn’t this DevOps thing solve my client’s problems

An important part of what I do today is about helping foster the same kind of curiosity in others, and helping hone in the skills to make the best use of that curiousity.

Examples of times you should ask — Why

Hint: If you’re not sure — always ask why.

You’ve been invited to a meeting, with no description or context, and no idea what the outcome is.

You’re creating a presentation as a team but you haven’t agreed on the audience, the intention or the outcome.

You’ve been told to create a kubernetes cluster.

You’ve been told stand-ups happen at 9am (and they happen to go for 45 minutes, nobody seems to have an understand of what to do for the rest of the day even after the meeting).

You’ve been asked to join a new project, team or a recruiter has told you they think you’re “perfect for Job X”.

Your company has decided they’re moving to the Cloud.

Why we ask why

Okay so that heading was very meta. The intention isn’t to challenge or be confrontational. It’s not a power play or a fun party trick.

Asking why is about having a shared understanding.

In each of the previous scenarios and indeed in many interactions there’s always an underlying intention. Sometimes it’s just about communicating with each other to gain that shared understanding.

Warning: Here be dragons. Sometimes (e.g when people aren’t sure why) asking them can lead to defensiveness and well, make them angry. Other’s don’t like being interrupted or challenged. Some people have values and principals that favor hierarchy over creativity and innovation. Asking why isn’t always a happy path to making friends.

What does all this have to do with Business Value?

Business Value should be well known and clearly articulated in every team of your organization. Everyone should know the why (and how what they’re doing ties back to a very specific business value). Your business should have a way to measure the business value (so you know when you’re done). Everyone should be contributing to the business value metrics, and collaborating to get it done together.

Assuming you’ve done the hard work of figuring out what your business is trying to do (you understand the business value and have some metrics to measure against) the next part can be fun and rewarding!

Why haven’t you talked about DevOps yet?

Let’s assume (like many companies today) you “develop software as part of an effort to provide products & features, to give you a competitive advantage”.

Where I think “DevOps” has failed us is the misconception that it’s “half dev” and “half ops” and that problem lies in the very core of DevOps — It’s name! But in reality without software there’s nothing for “Ops” to do.

Customer leads to Business Value leads to Software. How we build, test, deploy and operate our software is important but we can’t call it DevTestSecQADeployOps so let’s just call it Good Software Delivery Practices.

Good Software Delivery Practices

You’ll likely want to incorporate automation and optimizations that allow you to “produce working (aka releasable) software every sprint” and reduce manual steps in favor of automated ones where rework is likely to occur.

You’ll want to “drive value through the system” and this usually translates into working on new products and features that benefit your customer (hopefully identified by your product team’s close relationship with it’s customers).

Your product/development team might also decide to operate in some flavor of “you build it, you run it” team which encourages them to build good quality software with resilience and alerting that’s actually helpful.

If I know I’m going to be woken up at 3am when things go wrong it’s going to fundamentally affect my choices when designing and operating my software (hint: for the better).

Ultimately when you combine “Business Value” with “Good Software Delivery Practices” every choice you make has clarity. You know “why” you’re doing something and you can trace it back to a specific metric that has a positive impact on your business (and by that I mean improving the lives of your customers in some way).

So when you go to that next meeting, or pickup your next Jira ticket from the “todo” column ask yourself:

Do I know why am I doing this?