DevOps for the Agile Leader

Lee Eason, Executive Director, Technology, IHS Markit
Lee Eason, Executive Director, Technology, IHS Markit

Lee Eason, Executive Director, Technology, IHS Markit

Agile companies need DevOps in a cloud-based world more than ever

Put simply, DevOps is an environment where the habitual improvement of the code, build, deploy, and monitoring processes are rewarded.  Business agility promises that the sooner you can react to customer and market feedback, the more value you'll deliver.  DevOps is critical to keeping that promise because it makes the process of deploying that value a core aspect of product development.  If you capture feedback from users and quickly develop a valuable change, but it takes six months to move that to production, then the value of capturing that feedback is diminished.  If your competition can capture feedback and get changes to market once a day, who do you think has a better chance at winning?

 

Taking time to improve technical process is like a pit stop. The goal in Nascar is to win the race by completing laps faster than everyone else. You have to stop racing for a few seconds to get new tires and fill up on gas. If it is so obvious to a race team that a pit stop is necessary to win, why is it so hard for companies to let their development teams do it?

 

The role of the Agile Leader

The answer is because people who understand the value of DevOps related work are not usually good at selling it. What seems self-evident to a person who has spent their career deep in the weeds of technology can look like a distraction to a non-technical person. Agile process leaders such as scrum masters, agile coaches, and product owners, on the other hand, are natural influencers. What we need then is to educate agile leaders on the value of DevOps work, and help get technical process improvements prioritized. Rather than treat DevOps and Agile transformations as two separate efforts, recognize that they are co-dependent and get your agile leaders involved in driving DevOps work.  This need is exacerbated by the explosion of public cloud.

 

The sea change of public cloud

IT exists to balance the need for shared infrastructure against team independence. IT allows development teams to avoid having to buy their own network equipment or staff specialized skills. The downside is delays, as getting a new server can take weeks. DevOps, by itself, doesn't fix the problem of shared infrastructure.  That’s why when Jeff Bezos saw how much time was being lost in teams coordinating with each other at Amazon, he put a rule in place: teams cannot coordinate dependencies in person. Instead, every team at Amazon, including IT, had to build an application that allowed other teams to consume their services without human interaction.

 DevOps is an environment where the habitual improvement of the code, build, deploy, and monitoring processes are rewarded  

Amazon ITs application allowed thier teams to request a new server or networking change. It would make those changes automatically to the underlying infrastructure. This is what grew into Amazon Web Services (AWS), which launched in 2006 and started the public cloud revolution. I remember the first time I saw it in action. My fellow developers and I felt like liberated prisoners.  No longer would we be shackled by the cruel task maskers of IT.  We were free to deploy infrastructure whenever we wanted. For a short while, it was heaven.

 

Soon we realized we were missing something. Developers did not know how to setup a secure network, backups, or patching.  Servers got hacked, services went down, and company leadership scrambled to react.  It turns out developers had not been prisoners, but rather unappreciative consumers of IT who had been working diligently to protect us and our customers from poorly designed services. To fix this, two shifts have been happening. First, developers are becoming less specialized, more T-Shaped, and more proficient with the cloud-based infrastructure they build services on. You can see this happening through trends like DevSecOps.

 

The second shift is the rise of Site Reliability Engineering (SRE).  SRE was created at Google in the early 2000s.  Google engineers like to say that SRE is an implementation of the DevOps mentality.  SRE is how teams using public cloud should be handling operations of their services and leads to things like automatic failure recovery.

 

Though non-trivial, these shifts bring major benefits.  To measure the payoff potential at one company I worked at, we looked at the number of infrastructure change requests that IT processed in a year. There were 1,500+ requests that could be automated and handed to development teams using public cloud.  On average, those requests took four days to complete by IT. That is over 6,000 days of friction that could be saved each year.  Healthy adoption of public cloud eliminates that friction.

 

Reducing lead time and the cost of delivering value gives your business a critical edge.  Faster recovery times also keep customer confidence and NPS high.  Recognize that your agile transformation goals depend on technical maturity, make sure your agile leaders truly understand that, and drive both DevOps and Agile through a common voice.

Read Also

Operational Visibility in the SDDC

Operational Visibility in the SDDC

Dirk Wallerstorfer, Technology Lead for SDN and OpenStack, Dynatrace
Ask Your Managers What They Really Need

Ask Your Managers What They Really Need

AshLea Allberry, VP-Operations, Nanonation, Inc.
The DevOps Culture Change Goes Way Beyond IT

The DevOps Culture Change Goes Way Beyond IT

Raman Sapra, VP & Global Leader, Dell Digital Business Services
When Do-IT-Yourself is Not Good Enough?

When Do-IT-Yourself is Not Good Enough?

Scott Cleland, Senior Director of Product Marketing at HGST, a Western Digital Corporation brand