“The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations“
By Gene Kim, Patrick Debois, John Willis, Jez Humble, and John Allspaw
IT Revolution Press, 480 pages
“Start and Scaling DevOps in the Enterprise“
By Gary Gruver
BookBaby, 94 pages
Large organizations have always found it hard to scale agile beyond teams, let alone between different divisions. Doing agile and DevOps at a team level is almost effortless compared to how difficult it is to apply agile in a large organization like Allstate, Citi, or federal government agencies.
All of these organizations desperately want the benefits of agile and DevOps: speeding up the release cycle so that they can get the lean-like throughput benefits of removing bottlenecks and focus of creating software that makes users productive. As I like to call it, they want to put a small batches process in place to drive business innovation.
But it’s hard, way too hard. As the DevOps reports have found, organizations of 10,000 or more employees are 40 percent less likely to be high performers than “tiny” organizations of 500 people or less.
I talk with a lot of large organizations struggling through this change. They have to go through dramatic organization and process switches, often completely rebuilding both over the course of a few years. Many of them, like Allstate, go so far as to set up separate organizations so as not to hamper and infect the new organization with the ways of the last.
In whatever you may think of as the “agile and DevOps intelligentsia,” there’s been much movement recently to help these organizations. The DOES conference is doing a good job in profiling how large organizations are improving, DevOpsDays conferences are similarly putting some large user stories on display, and vendors — like my company, Pivotal — are using their conferences to get large organizations to share their war stories and advice. We’re getting better at helping large organizations, but it’s taken a long time and there’s still much work to do.
Two recently published books stand out, here, as helpful and are worth your time if you’re struggling with scaling agile and DevOps.
Completing the DevOps Boxed Set
First is “The DevOps Handbook,” written by an all-star cast of DevOps thought-lords, Gene Kim, Patrick Debois, John Willis, and Jez Humble. This book delivers on its title: It’s a handbook for what DevOps is, the practices to put in place, why they work, and just enough case studies from donkey organizations to convince you that you don’t have to be Netflix or Google to find success with these practices.
When reading The DevOps Handbook, the book I kept comparing it to was “Lean Enterprise” (which Jez Humble also co-wrote, along with Joanne Molesky and Barry O’Reilly). I could never quite get through Lean Enterprise in a regular fashion, despite trying twice. It contained all the right things from continuous delivery, to Colonel Boyd and Prussian military approaches, to Westrum-think.
Where “Lean Enterprise” was an excellent sermon from the pulpit of DevOps (more like a sort of compendium thereof), the “DevOps Handbook” is more like a manual for putting The Good Work into practice. “Lean Enterprise” will sell you on why you should fix your organizations, help you understand a new way of thinking about organizations, and tenderize your mind to accept the instructions in the “DevOps Handbook.”
Another book, “Effective DevOps,” by Jennifer Davis and Katherine Daniels, is a good companion to both of these books. I liked “Effective DevOps“ because, in addition to covering the basics of DevOps, it speaks to the humane part of DevOps that I like most: we should try to do good work and do so by creating a healthy, smart workplace and processes. It gets into plenty of hands-on advice as well, both in the meatware and software stacks. This is the cheery, optimistic way of phrasing my overly cynical summary of all software methodologies: don’t do dumb shit.
Run the Pipeline Green or Gruver will Melt You with His Laser Eyes
While the “DevOps Handbook” is definitely worth your time, you should first grab a copy of Gary Gruver‘s new 94-page book, “Start and Scaling DevOps in the Enterprise,” and plow through it before doing anything else. The writing in this book is as clear and intense as that stare he always manages to kick up in his headshots. It’s like cleaning the confusion of your upstairs junk closet by painting it with the business end of disintegration ray.
Gruver’s book starts with the premise from above: putting DevOps into practice for small teams is no problem. Scaling it to hundreds, if not thousands of staff is a whole other pig to roast. And, as I find so often in my travels, the majority of the world’s software problems are cracking the nut of applying agile and DevOps projects at scale.
Solving this scaling problem will have the largest net-positive effect in our lives: if you could improve the effectiveness of software at government agencies, for example, in health care, retail, or industrial machinery management by just a few percent each year you’d improve the lives of many more people than by putting more hats on cats.
While it’s true that problems can sometimes be reduced down to just one team, most systems in large organizations – many of the ones that generate core revenue — are big, complex, and scary. As an illustration of an inescapably complex system, Gruver describes putting an omnichannel strategy in place:
For example, in retail where companies are trying to create common experiences at every customer interface, creating the capability to buy online and pick up in-store requires coordinating the work across large, tightly coupled systems. It impacts the website and mobile teams for ordering. It goes through credit and inventory systems that are typically on legacy systems. Then it goes through the point of sales systems and tools for the stores. These systems are so tightly coupled that moving to buy online and pick up in-store requires coordinating the development, testing, and deployment across all those systems.
His prescription isn’t effortless to apply and is hellishly-strict compared the rainbow and sandals vibe you get from most DevOps advise. At the core of his approach, Gruver insists on using automated deployment pipelines with an ever-growing cadre of automated build acceptance tests to governor individual projects, but also the integration of multiple projects. He somehow manages to explain applying bounded context thinking to breaking up complex systems (like the omnichannel one above) with uttering the phrase “bounded context.”
What I find so helpful, and even thrilling, about Gruver’s book, is that it’s exacting in its instructions and walks through several what-if scenarios for addressing common problems that come up when applying agile and DevOps at scale. Plus, it’s the perfect size for a book of this type: about 90 pages that’ll take you about 90 minutes to read.