Is DevOps Your Achilles Heel Or Your Catalyst For Innovation?

What is the single best indicator of technology maturity?

I have worked with hundreds of companies of all sizes and have boiled it down to one question – how frequently can you deploy software to production?

The typical answer is monthly, however, many companies – pre-modernized and typically Fortune 500 – deploy on a quarterly basis. The few companies (less than 5%) that have evolved into a live-testing or testing-in-production workflow are considered very mature, they deploy on a daily or even hourly basis.

The main reason we use frequency of deployment as the primary indicator of engineering maturity is that it forces all other competencies downstream to be optimized. You can’t deploy daily unless your quality engineering function (testing) has been automated. You can’t deploy daily unless your cloud infrastructure is also automated. You can’t deploy daily until your DevOps processes have also been automated.

Automation of the four categories above is the ultimate manifestation of where you are on a maturity continuum across people, processes, and tools/technology.

The Unlikely Key to C-Suite Nirvana

It seems like every leader in every software company is dealing with a different headache that makes organizational nirvana seem unattainable.

Your CFO and CIO are stressed about rising costs. Your CMO sweats every negative interaction customers have with your brand. Your CPO is trying to figure out how to increase your speed to market without sacrificing innovation. And the CEO cares about all of it.

It feels like simultaneously cutting costs, improving brand equity, and increasing speed to market without derailing the good things we have going on in each department would take a complete reimagining of our organization.

Or, maybe, it just takes a complete reimagining of how we approach DevOps.

You’ve Got a DevOps Problem…And You’re Not Alone

DevOps has traditionally been influenced by a waterfall perspective – understand all the requirements up front, build some monolithic application, deploy it, then deploy updates quarterly. The process hinges on Continuous Integration and Continuous Deployment (CI/CD), which has become a buzzword, just like Digital Transformation (consider that foreshadowing).

Most organizations will tell you they are doing CI/CD when they are only doing a part of it and not getting the full benefits. CI/CD is about continuous integration and continuous deployment. Integrating and deploying quarterly is not continuous, neither is doing so monthly.

Cost and Customer Experience

The brutal truth is when most companies do monthly or quarterly releases, they have too many folks on the line, working late hours to do a release on the weekend. They’ve also stood up multiple static environments they just let run in the cloud. All of that costs money.

They rarely have automated testing. Human intervention means human error, and that means deploying bugs to customers. Each time you do that, your brand equity takes a hit. Customers’ goodwill diminishes because they’ve been given a subpar experience. Employees’ goodwill diminishes because they are staying up late to work in outdated processes with outdated tools.

In this process, companies with really smart people and innovative ideas end up spending more money to give their customers a worse experience.

Product Limitations

The importance of the relationship between product and engineering teams cannot be overstated. If an organization’s product team is modernized and working in an iterative fail fast approach, but their engineering and DevOps side is not, they have a bottleneck. No matter how fast they iterate on the product side, they can’t push anything out and get true customer feedback for a month or, often, an entire quarter.

Too often, DevOps can be the Achilles heel of a potentially great product organization when it should be a catalyst for innovation.

DevOps A Better Way

Today, I’d estimate 90% of technology leaders consider themselves agile, but their practices suggest more of a scaled waterfall approach. They’re still doing a ton of research on requirements and doing quarterly releases. Just because a team works in two week sprints does not make them agile.

Being truly agile is all about how quickly you can pivot on a dime and deploy. More simply put, how quickly you can respond.

Even (maybe especially) the most passionate engineers will tell you DevOps is not an appealing practice. Frankly, it can be nasty. There are lots of configuration files. You’re not necessarily writing or creating. You’re organizing, grabbing, and translating. You don’t write sexy feature code, you take that code and get it into a cloud environment and make it available.

There are some barriers that keep companies from investing in DevOps, chief among them, I believe, is that so few companies understand what truly great DevOps look like, and the impact that greatness can have on cost, brand equity, and speed to market.

Great DevOps is possible. At Headstorm, we call it Extreme DevOps.

More Automation, Fewer Environments, Greater Speed

With Extreme DevOps, if your product team comes up with new features or responses to consumer requirements, they don’t have to wait a month or quarter to push them out. They have to wait an hour. In the process, you’ll see a major reduction in cloud costs and improved brand equity.

Here’s how…

The purpose of lower cloud environments is to serve as stage gates for your QA team to jump in and test each time the code has been promoted. All of those require care and feeding and all of them are a drain on your cloud spend.

The whole process is outdated and it kills your speed to market. When an organization says they’re running a two-week sprint, they’re actually saying they have a two-week development sprint and one week of QA sprint, and perhaps even another week to fix whatever the QA team may discover.

So, in reality, a two-week sprint often runs on a four-week release cycle.

DevOps automates that process. When a developer submits code, a cloud formation is spun up, all of the testing is run, and if all the lights are green, it immediately gets merged into production.

This is where the cost savings really kicks in. You condense your environments from four to one, saving an average of 40% in cloud costs.

You can also shut down your QA capability. Hiring QA business analysts is an old school way of working. Writing the tests has been transitioned to the development team. That allows you to push directly to production.

When you do that you have fewer bugs, and you have a much faster response to the bugs you do have.

You no longer have to push out a quarterly release and come back the next quarter to clean up the mess it may have created. Now you can iterate on your customers’ new feature feedback. When you push daily, you can get immediate feedback that you then incorporate back into the product life cycle. Simply put, you iterate and learn much faster.

DevOps Encourages Innovation

In addition to speeding up the go-to-market process, DevOps also increases an organizational appetite for innovation.

If an innovative feature carries a degree of risk that you can’t retract for three months after pushing it out, you’re less likely to try. If you can push it to production, get immediate feedback on it, especially negative feedback, you can pull it back in a matter of hours or minutes, addressing anything that needs to be fixed or improved.

By overhauling and modernizing an often-overlooked part of the engineering process, the CIO can simplify a process that delights the CFO by cutting cloud costs by 40%, the CMO can go full steam ahead on brand initiatives without worrying about a potential setback in customer satisfaction each quarter, and the CPO can get new features to market faster and innovate on real customer feedback, and the happy CEO can take everyone out to dinner.

Nirvana.