Introduction

WHAT’S IN YOUR PLAYBOOK?

In April 2016, the Villanova Wildcats played the North Carolina Tar Heels in the 2016 NCAA Basketball National Championship Game. The game was the greatest ever, and it all came down to one last play, with just 4.7 seconds left on the clock. Joel Berry II hit a three-pointer to tie the game at 74 apiece, and Villanova Coach Jay Wright called his final timeout. In the NCAA, you have to go down the entire length of the court after a timeout. Immediately, Kris Jenkins of Villanova inbounded the ball to point guard Ryan Arcidiacono. Arcidiacono dribbled down the court past Berry, but it was the design of the play on both sides that made for the great ending. UNC played a 1-3-1 man-on-man press to Arcidiacono, to hopefully force a turnover, but if Arcidiacono got past Berry, they had Justin Jackson, Isaiah Hicks, and Brice Johnson, all who could stop the three-point shot. Villanova had designed a play to make sure that Arcidiacono got the ball off the inbound in a position in which he could get past half-court and find someone on the three-point line. Arcidiacono got past Berry, UNC collapsed, and Arcidiacono popped it back to Jenkins on the three-point line to get an almost-uncontested three-pointer to win the championship, and boy did it pay off. #Win!

—By Saransh Sharma (Sharma, 2016)

A Playbook for Adopting DevOps at Scale

Teams that excel do so not just because they have the best members, the best tools, the best training, the best processes, or the best leaders and coaches. They excel because they, as a team, have all of the above but also know what to do when they face various situations and challenges. They have a playbook of potential solutions (plays) for a variety of scenarios.

When faced with a unique situation or challenge, the players and coaches come together as a team to pick the right play from the playbook, and then, most importantly, they execute it. My alma mater, Villanova University, won the national championship when it came down to the final play, with seconds on the clock, because they had plays they had practiced before. They read the situation, picked the right play, and executed with precision to win. Had they not had the play that would catch North Carolina off guard, there may have been a different outcome.

In the same way, IT organizations need plays to execute. For day-to-day application delivery and operations, these so-called plays are captured in their development, delivery, and operational processes. IT organizations that succeed have good processes and execute them with excellence. However, transforming IT organizations is another story. Most organizations struggle with transformations, not having well-defined, winning plays that can overcome cultural and organizational inertia. This book captures a set of proven, repeatable plays for adopting DevOps at the enterprise scale and for transforming a large, complex, distributed IT organization to adopt DevOps.

These plays come from my experience over several years in the trenches as I helped dozens of organizations, of myriad sizes and maturity levels, in a variety of industries and geographical locations, to adopt DevOps. Since the early days of DevOps, as the Worldwide CTO of DevOps Technical Sales and Adoption at IBM, I have had a front-row seat to see the evolution and maturation of DevOps from a set of practices pioneered by startups to a cultural and technological transformation effort in large enterprises. I was a pioneer and thought leader for DevOps at IBM, and I became the face of DevOps to IBM’s clients. This book distills patterns of success that I have observed among hundreds of clients working, struggling, and succeeding at adopting DevOps at organization or enterprise-wide scale.

Adopting DevOps in a small, co-located organization, without a lot of cultural memory, is not difficult. Even in large organizations, small teams—the proverbial two-pizza1 teams—regularly succeed at attaining the business results promised by DevOps. In most organizations, you see many such efforts made, and most succeed. It is taking that success from an individual, isolated team level and scaling it to an enterprise that is a challenge. It is like having a series of small dance squads around the organization. However, these dance squads are all unique; some are doing the salsa, some jazz, some are ballroom dancing, while yet others are doing something my daughter tells me is “hip-hop.” They cannot combine and grow to a massive dance ensemble that can perform at the next halftime show, filling up the entire paying field of a football stadium. For that they need to be dancing not only to the same music but also be performing the same dance form, in unison. Similarly, small unique teams cannot impact the entire organization. These teams need to make the effort to standardize practices, processes, platforms, and tools in order to allow them to be replicated in other parts of the organization.

The organization, in turn, needs to set the right environment for DevOps adoption by sponsoring transformation efforts, by enabling change to rigid legacy processes, and by a top-down push to overcome cultural inertia.

    NOTE      A bottom-up practitioner-led effort allows extremely productive individual teams to adopt DevOps and thrive. A top-down executive leadership-led effort enables these individual successes to scale.

The engagement of the business is imperative for these scaling efforts to succeed. IT organizations exist to deliver the capabilities a business needs in order to deliver business value to its customers. The business is asking the IT organization for optimization—to be more agile, to be resilient to change, to be more responsive, to do more with less, to be more productive, to increase throughput, to deliver faster, to deliver at higher quality, to be reactive to the market, to accelerate past the competition, to keep up with an ever-changing regulatory and compliance regime, and, yes, to reduce expenses.

In addition, it may also be asking for innovation—to allow the company to enter new markets, to enable exponential growth, to engage and grow the customer base, to be responsive to customers’ needs, and, again, to reduce expenses. Delivering on these asks (hopefully not all of them at the same time) is what drives the need for change. It is what creates the motivation to work toward achieving the benefits that come from adopting DevOps.

    NOTE      You do not just adopt DevOps because it is cool. You need to have a business reason. The need for agility or velocity is the number-one reason that DevOps exists. The maturing and wide adoption of DevOps over the last few years is a reflection of today’s dynamic marketplace, of customers’ expectations.

Thus, in order for IT to undergo a transformation, this change has to improve and enhance IT’s ability to deliver business capabilities in a manner that, in turn, improves and enhances the business value delivered. Proper partnering between the business and IT is imperative so that the transformation IT undergoes by adopting DevOps delivers what the business needs the most by properly balancing optimization and innovation. Business goals have to drive why IT transforms, which will in turn drive how IT transforms.

This book will categorize DevOps adoption plays as follows:

• DevOps for optimization
• DevOps for innovation
• Scaling DevOps adoption for the enterprise
• Driving DevOps transformation in the enterprise

It will include lessons learned, examples, success patterns, and anti- patterns for each adoption play. Like a sports playbook, this book is designed to deliver certain plays that can be executed for different scenarios and situations—depending upon your organization’s current maturity and state—when it comes to transforming to a high-performance application delivery organization by adopting DevOps. An organization will need to take those plays and execute them in a tactical manner, based on the projects and teams that are adopting DevOps. Just as no battle plan ever survived contact with the enemy, these plays will need to be executed with an action plan or a broader adoption roadmap designed for each organization.

Furthermore, no organization is monolithic or homogenous in nature. Some parts of the organization may be more mature in some areas, but less mature in others. Some teams and groups may have already achieved agility and velocity, whereas others may be experiencing tremendous cultural inertia, all within the same organization, sometimes in the same building; they all need to work together in order to get scale.

An organization may have an innovation lab that is using modern agile and DevOps practices, while core systems teams may still be delivering in a rigid waterfall manner. Thus, these patterns of adoption will apply differently to different parts of the same organization and will need to be customized to suit the needs of various teams. To help with this customization effort, this book will also apply the technique of value stream mapping, used for decades as a component of Lean practices, that can...