DevOps is Coming and It's About Damn Time!

6 minute read
Stephen Fishman avatar

We have all felt the pain of the schism. In corporate America, it is everywhere. You go to a meeting, it is there. In the offices when the doors are closed, it is there. Even in the cafeteria and in the elevator it is there. The pain of schism between the business is so palpable and so wide spread it has spawned a manifesto and a movement. Oops -- I misspoke! It has spawned two manifestos and two movements.

Agile's Lesser Known Twin Sibling

Unless you have been living under a rock, you have heard of agile. Agile was meant to heal the schism and it has done a lot, but it simply cannot do the whole job by itself because it stops too soon. When the right sort of people are combined with agile principals and tactics, good things seem to happen. Agile's focus is at the front lines -- between the business and development. DevOps applies the same sort of principal based model to the inner workings of the IT machine.

About 9 months ago I was at SXSW and I went to a talk entitled "When IT Says No" given by Gene Kim. I thought I was going to a UX talk about how product professionals can learn to improve their relationship with IT departments. What I found was something completely different. Gene wasn't talking about UX at all. Gene was talking about the schism between software development and IT Operations and how DevOps was inspired and designed to heal the schism inside of IT.

Gene and I got to talking after his session and each of us came to a state of giddy excitement as we discussed IT Kung Fu, relationship dynamics, and the application of spiritual philosophy and the humanities inside of IT and business settings. Eventually, Gene and I got to talking about the books he was working on and that his adaptation of the hero's journey was almost complete. Fast forward 9 months and the book launch is upon us. I had a chance to talk in depth with Gene about the book and his mission to change the lives of IT professionals everywhere.

The Phoenix Project

Gene is an ardent believer in the power of story to teach and wrote the book in the form of a novel: The Phoenix Project: A Novel About IT, DevOps and Helping Your Business Win, taking 

Thumbnail image for ppcover-3d.png

his hero, Bill Palmer, on a journey that is a melding of two classic business novels -- The Goal by Dr. Eliyahu M. Goldratt and The Five Dysfunctions of Team by Patrick Lencioni. Bill is promoted to VP of IT Operations and is quickly mired in series of events that will bring his company to the brink.

Bill and the other characters in the book are department leads that are presented as a series of archetypes:

  • Wes - The angry IT director, quick to point his finger right back at the business
  • Patty - The egghead director of IT Support with an academic answer for every issue
  • Steve - The hard charging CEO who has become a bit too removed from the realities of his team
  • John - The rigid Chief Information Security Officer (CISO) in a constant DEFCON 1 posture
  • Sarah - The narcissistic SVP of retail operations constantly politicking her way to the top

As Bill struggles to pull his IT Operations team out of a state of constant chaos, he gets introduced to a shamanistic, eccentric IT teacher, Erik. Erik uses the Socratic method of teaching to help Bill see the "Three Ways of DevOps".

Learning Opportunities

The Three Ways

The first of the Three Ways is to recognize and apply systems thinking to IT work. In applying systems thinking to IT processes, a DevOps practitioner must place value on the performance of the entire system, as opposed to the performance of a specific silo of work or department. This First Way emerges from an idea called the "Theory of Constraints".

The "Theory of Constraints" states that all improvements within a system that do not relieve the prime bottleneck either have highly-limited value, or are not actual improvements at all. From the systems level view, if you look at an IT department as a manufacturing shop-floor:

  • an improvement before a bottleneck will result in additional work piling up at the bottleneck
  • an improvement after a bottleneck will result in idle time at the local work station

If throughput of features and enhancements is the macro metric to be optimized, mastering the First Way and applying the theory of constraints is an absolute must-do.

The Second and Third Ways are focused on creating feedback loops and culture of learning and experimentation. When properly utilized, the Three Ways drive an enterprise towards an IT team capable of rapid adaptability and etsy-style deployment systems and processes that can scale up to double digit deployments in a single day.

The Stakes and The Goal

Gene and his cohorts behind the DevOps movement are men who have found their calling. From a financial perspective, they see a dystopic IT and business culture throughout corporate America where global IT spending is moving past US$ 10 trillion and a failure rate for IT projects that approaches 70 percent. When you recognize that nearly 50% of IT work is either unplanned work or rework, a conservative estimate would be that 20% of IT work is wasted. Per the DevOps manifesto, "that’s US$ 2 trillion of value each year that we’re letting slip through our fingers."

This colossal waste, combined with the human cost of years of frustration, pain and suffering by IT workers all over the world have led the DevOps team to their mission -- to improve the lives of 1 million IT workers within 5 years. The more I talk with Gene and the more I read his work, the more of a true-believer I become. Given that I've already started applying and sharing the DevOps lessons with my team and my leadership, I'm doing my part. If saving US$ 2 trillion and improving 1 million lives sounds compelling to you then get ready, order the book and pass along the message -- DevOps is here to help us all, we only have to be open to unlearning some of our current ways and trying some new ones.

Editor's Note: Want to read more of Stephen's work? Check out: Finding the Cure to the IT Requirements Fallacy or Earth to Inge: Your Employees Don't Need You!