Master the First, Second and Third Ways of DevOps

This week I had the pleasure of hearing Gene Kim speak about DevOps and release management again.  Although I’ve seen Gene present multiple times, I always leave his talks with more insight than the previous time.

During this presentation, it was Gene’s description of “the three ways” that caught my attention.  For those of you who haven’t read Gene’s book, The Phoenix Project, the hero, Bill, is introduced to the three ways by a mysterious and sometimes frustrating mentor named Eric.  With Eric’s help, Bill learns about the three ways.

The first way: Flow

Flow is understanding how work moves through your process, how it flows from left to right.  The message that really stood out to me was not letting local optimization cause global degradation.  I’ll readily admit I have been guilty of this in the past, partly because I felt trapped in a silo and had specific MBOs to meet, which of course were silo-specific.  While I had supportive management, it was not always possible to work within company culture to work across silos.

The second way: Feedback

Frequently, when managing software releases I have seen information flowing from left to right, from dev to QA to production teams.  There is minimal opportunity for feedback and, often, little time allocated to react to feedback when it is received.  The second way stresses the importance of feedback, from right to left in a process.  In order for this to be successful, the feedback loops should be short so that information is received in a timely manner.  Continuous improvement must be integral to your process and the feedback loops need to provide information to feed the continual improvement.

The third way: Experimentation and Learning

Gene also talked about failing fast, which is part of experimentation and learning.  Develop a minimally viable product (MVP), get feedback and if, for whatever reason, an idea isn’t working out, abandon it or change course quickly.  In my experience, the longer you work on a project, the harder it is to convince people to change course, no matter how compelling the data proves that change is needed.  Developing a minimally viable product is a great way to get feedback in a timely manner when there is still a high chance feedback will be acted upon.

My only gripe with the MVP model is that, all too frequently, teams seem to deliver a minimally viable product and then go onto the next big thing.  So, what starts as a great MVP and is compelling to users, ends up as a product that does not meet expectations.  Revisiting MVP’s to make sure that they remain competitive is as important as adding new features.

No matter what vertical market you are in, mastering the three ways will help your company become a high-performing organization.  For more about the “the three ways,” check out Gene Kim’s The Phoenix Project.  I highly recommend it.

Share this post:

Leave a Reply