As I have begun following the DevOps movement over the last year, one of the most interesting topics has been applying “Lean” principles to the DevOps problem. I suspect that many of you have heard of Lean, but if you are like me, it may not be immediately apparent what they really means. Even though I started my career as a developer, the advent of lean methodologies in software development in the guise of Agile Development was after my time in the trenches.

So, I won’t attempt to give an in-depth overview of Lean, but need to discuss the basics here to talk about how it applies to DevOps. Lean started out within the manufacturing world, specifically in Japan at Toyota. Basically Lean methodology seeks to eliminate the expenditure of any resources on any activity that doesn’t create value for the end-customer. When apply correctly, this is revolutionary. A maniacal focus on the end-customer means that waste isn’t tolerated. It also requires an end-to-end perspective that looks at all inputs and focus on the end goal.

The lean concepts made their way into software development through the  Agile Development community, particularly due to the efforts of Tom and Mary Poppendieck. Their website provides a great overview and we’ve got upcoming interview series for you to read as well. The short version is that Lean Software Development seeks to eliminate the same soft of non-value producing waste that Toyota first attacked in the 80’s. The main difference is that the focus is on time wasted (man-hours), and the inputs and outputs are digital. As you learn about the core principles, you can see that most of them are procedural, organizational, and cultural in nature – not tools based.

So, we finally get to DevOps – and particularly the Ops-ish side of DevOps. How can these same principles be applied? This is an incredibly interesting and complex question, but let me throw some basic ideas out there for consideration:

  1. Operations needs to focus 100% on producing value for the customer/end-user (this may be internal or external)
  2. Operations tends to focus first, and are measured on, on stability and risk mitigation first, not customer value. Culturally all of IT needs to move towards a business, and customer focus.
  3. Processes should be built, and re-designed, to eliminate wasteAgain, this is not a natural act for Operations. There is often a perverse incentive to be the “hero” – working late through the night and doing prodigious amounts of manual work. The rank and file of operations teams need to incentivized to eliminate wasted effort and time through automation, solid processes, and by eliminating bureaucratic nonsense.
  4. Organizational silos are an obstacle to success. This is core feature of lean software development, and operations needs to adopt it. Separating different skills into neat, matrixes organizational structures may look on paper, but it wastes time in reality.
  5. Software tools should have to increase customer value to be purchased. As I have said in other blog entries, it is the knee-jerk focus on tech before business value that dooms so many IT shops to mediocrity and failure. A software implementation without a business case and solid metrics for measuring business value is a waste of time. Bottom line.

I hope to spend some more time on this subject, but I hope you can see the immense potential for change that lean could bring to operations. It has been tried before, but my opinion is that the inherent business and customer focus inherent in DevOps has the most potential to push these changes into Ops, once and for all.

By Ben Newton