Quick Guide to DevOps for the Non-IT Business Leader

Adapted from War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age by Mark Schwartz.

What is DevOps

1) Small Teams of T-Shaped People

DevOps is practiced in small teams, say five to nine people. Small teams can communicate among themselves face-to-face, thereby avoiding the overhead of passing around and perfecting documents. Each team is cross-functional, with skills in software development, testing, infrastructure engineering, operations, and security.

These functions are not necessarily represented by different people. In fact, DevOps organizations prefer what they call T-shaped people: employees who have a broad set of skills but go deep in one area. They’re generalists who have a specialty; for example, a particular team member might be able to develop software and engineer infrastructure, but is especially good in performance optimization. Teams of T-shaped employees are very agile because they can pass work back and forth as needed, and yet draw on deep expertise when necessary. You may recall that in Chapter 1 I discussed the problem with fracturing skill sets into silos; the T-shape is a solution to the problem of needing deep specialization, but wanting people with diverse skill sets.

2) Automation

DevOps teams rely heavily on automation (in geek speak they say, “Automate all the things!”). They automate their testing, as well as their infrastructure setup in the cloud. They automate controls that monitor for security and regulatory compliance. And they automate the process of merging code from developers and resolving conflicts.

3) Frequent Deployment

What is most remarkable about DevOps is its emphasis on deploying code to users very frequently. The movement entered the IT community’s consciousness in 2009 when Flickr, the photo sharing site, announced it was regularly performing ten deployments every day. By today’s standards that’s nothing—Amazon.com is probably the current leader at over fifty million deployments per year. In fact, how often they’re able to deploy valuable changes or new capabilities has become something of a point of pride with DevOps practitioners.

4) Lean

From a Lean point of view, DevOps is  .  .  .  well, very lean. There are no handoffs to external groups because the cross-functional team has all of the skills it needs to do its work. Features are completed and immediately deployed, so there is little work in process. Automation reduces the work the team must do to produce each feature. There are fewer defects and less rework because the automated tests find problems quickly.

5) Reduces Risk

It might sound risky or chaotic to deploy changes to users so often, but it’s actually the opposite. In the past, IT teams have made large, infrequent deployments that invariably did cause chaos for the rest of the business and for themselves. But with DevOps, each deployment is small and therefore unlikely to fail; if it does, the problem can be quickly found. In addition, the deployment process itself is well-tested because it’s used so often.

Attuned to the Digital Age

DevOps, you may have noticed, is attuned to the speed of the digital age—a fast process for fast times. In Accelerate, Dr. Nicole Forsgren, Jez Humble, and Gene Kim write:

^{Our analysis of high, medium, and low performers provides evidence that there are no tradeoffs between improving performance and achieving higher levels of tempo and stability: they move in tandem. This is precisely what the Agile and Lean movements predict, but much dogma in our industry still rests on the false assumption that moving faster means trading off against other performance goals, rather than enabling and reinforcing them.}

Statistically Proven Results

The DORA study used cluster analysis to separate companies into cohorts based on their IT performance. To measure this they used a construct they called SDO (software delivery and operational performance) that brought together measurements representing throughput, stability, and system availability. As proxies for throughput they used the frequency of IT feature deployments and the lead time from when a developer finishes coding an IT capability to when it’s deployed. To represent stability they measured the change failure rate and the mean time to repair (MTTR) problems. Based on SDO, they were able to cluster companies into four performance groups: low, medium, high, and elite performers.

Comparing the elite performers (who use DevOps best practices most extensively) to the low performers, they found that the former are able to deploy features 46 times more frequently, show 2,555 times faster lead times from the point of finishing code to deploying it, are 2,604 times faster to recover from downtime, and are only one-seventh as likely to have a change fail (according to Forsgren and coauthors in Accelerate). 

Reduce Risk and Cost

It’s not surprising that DevOps practices are correlated with good business results. For one thing, these practices reduce many types of risk. Security risk is reduced both through frequent testing and fast response to vulnerabilities when they are detected. While a waterfall project risks virtually its entire budget by not delivering results until the end, a typical Agile project risks only the cost of the increment under construction. And DevOps, with its fast, frequent deliveries, risks only the tiny increments between deployments.

DevOps practices also reduce costs. By quickly deploying a minimal product and then adding to it incrementally, your organization is able to stop wasting effort on unneeded features, or features that customers don’t actually want. Costs also decrease as the company finds ways to make the delivery process leaner. Since DevOps reduces defects it also reduces unplanned work. And finally, it seems to allow the size of delivery organizations to scale without diminishing returns.

Provides Business Agility

You can control a DevOps initiative through continuous involvement and feedback, rather than by simply approving a plan at the beginning of an effort. Instead of checking on the project through periodic status reviews, you get to see and use completed work throughout—a much better way to gauge progress. You can continually adjust priorities and reallocate resources, as well as evaluate the quality of the work by seeing business results, rather than through a few weeks of user acceptance testing at the last minute.

In short, you trade perceived control for actual control. In my view this means your expectations for technologists should actually be higher (and these expectations will be satisfied, because technologists are happy to be judged this way). You should expect that technologists will quickly and frequently finish and deliver results. That they will be of high quality. That technologists will work to reduce lead times, thereby becoming more responsive to business needs and reducing waste in processes. And that they’ll bring their creativity and passion to solving business problems, rather than waiting for requirements to be tossed over the wall to them.

Startup Success for the Enterprise

In his book The Lean Startup, Eric Ries draws out some of the business implications of being able to deliver products in a streamlined, lean way by showing how successful startups use an iterative approach to defining themselves. A startup begins with an idea and a vision for a product that it thinks will be attractive to customers. As Ries puts it, the company has a value hypothesis about which product attributes will be valuable to customers, and a growth hypothesis about how that customer value will translate into increasing revenues for the company. It then tests these hypotheses through marketplace experiments. Based on what it learns, the startup can continue with the two hypotheses as they are or “pivot”—discard them and formulate new hypotheses. This, according to Ries, is how startups succeed.

Ries summarizes the Lean startup process this way:

^{Identify the beliefs about what must be true in order for the startup to succeed. We call these leap-of-faith assumptions. Create an experiment to test those assumptions as quickly and inexpensively as possible. We call this initial effort a minimum viable product. Think like a scientist. Treat each experiment as an opportunity to learn what’s working and what’s not. We call this “unit of progress” for startups validated learning. Take the learning from each experiment and start the loop over again. This cycle of iteration is called the build-measure-learn feedback loop. On a regular schedule (cadence), make a decision about whether to make a change in strategy (pivot) or stay the course (persevere).}

Minimal Viable Product

The goal of a startup, then, is to achieve validated learning through experimenting, to maximize learning while minimizing investment. It does this by creating a series of minimal viable products, or MVPs—the smallest, cheapest versions of a product that will help the company learn and adjust course. MVPs can be surprisingly simple: perhaps at first, they’re onscreen mockups that can be shown to users to get their feedback. This could be followed by concierge products—that is, services having a Wizard of Oz–like “man behind the curtain” who performs the function that will later be automated.

The Lean startup approach is also used by established enterprises developing new customer-facing digital products, or IT systems for use within the enterprise. Instead of building from requirements, an Agile team should work from hypotheses: “We believe that if we create this particular feature, we’ll get this specific business result.” They can then test their hypotheses by creating MVPs. Testing ideas leads to better outcomes than asking users what they need. As Ries says:

^{The reason to run experiments is to discover customers’ revealed preferences through their behavior. In other words, don’t ask customers what they want. Design experiments that allow you to observe it.  .  .  .  [Minimum viable products] are real-life products, no matter how limited, that create maximum opportunity for us to be surprised by customer behavior.}

New Model for Business Success

Putting all these pieces together—DevOps, Agile, Lean Startup—we see a very different model emerging for how companies use IT. Instead of writing a requirements document based on what they think will be a good investment, they start with a business objective, generate ideas about how to achieve it, and run small tests to see if those ideas seem to advance the objectives  .  .  .  or, if not, how they can be improved. Small tests are possible because the IT team is using a DevOps practice that lets it quickly get features into users’ hands and gauge how effective they are.

In the past we’ve talked about making sure that IT is aligned with the business. But this is where the enterprise might want to align with IT. To gain the business benefits of DevOps and Agile practices, it must streamline all of its organizational processes, of which IT work is a part. Investment oversight, procurement policy, requirements formulation, and risk management are areas where companies can vastly reduce waste and lead times while actually improving controls. Until they do so, they’ll be sacrificing the speed and fast feedback that DevOps brings.

Think carefully about what success looks like. In the digital world, it looks like speed, flexibility, controls, and leanness—not like making plans and following them. It’s these new IT practices that will bring you those benefits. They have already brought them to the many other enterprises that have started down the path and, in some cases, disrupted industries.

Continue reading in War and Peace and IT by Mark Schwartz.

- About The Authors

Mark Schwartz

Mark Schwartz is an iconoclastic CIO and a playful crafter of ideas, an inveterate purveyor of lucubratory prose. He has been an IT leader in organizations small and large, public, private, and nonprofit. As an Enterprise Strategist for Amazon Web Services, he uses his CIO experience to bring strategies to enterprises or enterprises to strategies, and bring both to the cloud. As the CIO of US Citizenship and Immigration Services, he provoked the federal government into adopting Agile and DevOps practices. He is pretty sure that when he was the CIO of Intrax Cultural Exchange he was the first person ever to use business intelligence and supply chain analytics to place au pairs with the right host families. Mark speaks frequently on innovation, bureaucratic implications of DevOps, and using Agile processes in low-trust environments. With a BS in computer science from Yale, a master’s in philosophy from Yale, and an MBA from Wharton, Mark is either an expert on the business value of IT or else he just thinks about it a lot.

Follow Mark on Social Media

• 
•