Real benefits of adjoining DevOps culture to your Agile processes (supported by hard numbers)

Adopting the DevOps culture at your org translates into actual hard-dollar benefits. Don’t believe us? Read on to get the proof.

In his talk “Why Everybody Needs DevOps Now,” industry researcher Gene Kim said that “for a long time, Agile had been winning, but at the expense of the DevOps.” He said that back in 2013.

Agile has been in vogue since the early 2000’s, and it’s hard to find even one IT company these days that is completely un-Agile. Now, if we compare the development process to a facade of a building – since it really is what represents the industry – we may say that the exterior has undergone a major makeover thanks to Agile, while the plumbing, electrical wiring, and all other communications have been largely ignored.

That’s what DevOps is supposed to fix. Many call DevOps the next logical step in “agilizing” the development process. Others say it’s all about automating things that haven’t been automated yet. While this is all true, let’s see why a company cannot be 100% Agile without adopting the DevOps culture in addition to the Agile development process.

What is DevOps?

In the old days, developers would do their part, then “throw the code over the fence” for the operations folks to ship it in production. Since DevOps is an Agile Era creation, it’s about breaking old silos and fostering communication and transparency.

Hence, companies that follow the DevOps philosophy create more ties and dependencies between development and operations. This is especially important if you want to have a reliable, high-performance Continuous Delivery (CD) pipeline, which is, in a way, the “holy grail” of both Agile and DevOps.

DevOps is also about streamlining processes like provisioning and configuration, making full use of the modern DevOps tools, and making processes easily-replicable through automation. (One example of this is treating infrastructure as code, or the IaC approach.)

DevOps metrics

One (purely) DevOps metric is lead time – that is, the time it takes for the code to go from commit to production. Lead time is closely related to the number of commits per day (hour, second) and it demonstrates whether the org is capable of deploying code non-stop – which is what they call Continuous Delivery.

Being able to effortlessly tweak the software at any time is what lets one release new features, test hypothesis, fix defects, and put out fires much more efficiently.

But lead time is not the only metric to watch here. There is also uptime, or software availability. There are also rare – or unfortunately not-so-rare – critical events whose consequences are prone to subjective assessment, as well as post-mortem analyses that DevOps teams do after those events.

What I’m getting at here is that when these metrics improve, so does the efficiency of your software development. That means that you save much more money (man-hours, resources, etc.) in IT expenditures.

(Not to mention the proverbial “better software quality” that is also a consequence, although DevOps plays the enabler role here, rather than the root-cause role, as in the case with QA.)

The DevOps philosophy

Before we talk about the benefits, let me first say that DevOps is not necessarily a separate role or department at the organization. It’s more of an approach to delivering the software to production.

The DevOps philosophy can be described well using the CALMS acronym, which is also a popular DevOps framework. It stands for “Culture, Automation, Lean, Measurement, and Sharing.”

Culture = different departments work together on achieving the end-goal of delivering the software that satisfies the customer.

Automation = automating all you can; deploying continuously.

Lean = releasing software sooner, in smaller batches.

Measurement = measuring a limited scope of user-centric KPIs.

Sharing = the culture of shared responsibility.

Sharing could also mean reusing infrastructure setup, deploy patterns, etc.

The real benefits of DevOps

According to DevOps state of the industry reports (here and here), high-performing organizations beat their competition with:

Faster lead time. High-performers have a 440x faster lead time – that is, they have a lead time of less than an hour instead of more than a week.
More frequent deploys. They deploy code 46x more frequently – that is, they deploy multiple times per day, instead of once a week or less.
Greater degree of automation. High performers are 23x more likely to reuse deployment patterns for building applications or services. They have also automated close to 30% of their configuration management and testing.
Fewer defects. They have 5x lower change failure rate. That is, changes fail 7.5% of the time instead of 38.5%.
Greater product stability. Such orgs have 96x faster mean time to recover from downtime, which means they recover in less than an hour instead of several days.*

*A great illustration of why that matters is the famous AWS outage that occurred right in the middle of the AWSome Day conference in Edinburgh, Scotland. AWS’s Simple Storage Service (S3) went down, causing apps like IFTTT and Tinder to show blank pages to users. Most of the people at the conference looked down their phones and left; all except for the attendees that worked for Netflix. Netflix was the only company that day that was able to get the service back up almost momentarily, as opposed to hours later for the other companies.

Simply better performance. High-performing DevOps practitioners are simply 2x as likely to achieve or exceed objectives like operating efficiency, customer satisfaction, and organizational goals.

These are the real benefits that translate into money saved in the form of man-hours, resources, waste (waiting, taking superfluous action, etc.), reputation, and competitive advantage.

In conclusion

If you strive to be an Agile company and would like to do continuous delivery, adopting the DevOps culture is the next logical step that allows you to further streamline your operations, save money, and improve the quality of your product/service.

At the same time, you don’t necessarily need a dedicated DevOps department to achieve that. Tearing down “the wall of confusion” between development and operation, automating deployment patterns and other routines, and using modern DevOps tools will do that, as well.

Looking for professional DevOps services?Get in touch and let’s see what our DevOps engineers can do for you.Get in touch