The Devops Handbook Summary Series -3-Introduction to Part 1 - The Three Ways

·

4 min read

Hello everyone. In the past few articles, we briefly saw about the popular DevOps myths, the problems that existed before the adoption of DevOps and how adopting DevOps solved those problems

The book is divided into 6 parts containing a total of 23 chapters. In this post we will discuss a summary of the introduction to Part 1

Part 1 - The Three Ways

Let's see how different technology and management movements converged to set the stage for the DevOps movement.

In this part we will focus on the principles of Flow, Feedback and Continual Learning and Experimentation

But before that lets look at the factors that led to the formation of the DevOps movement, briefly.

The DevOps principles and practices are due to a convergence of many philosophical and management movements. These are the result of applying decades of lessons from the manufacturing, high reliability organizations, high trust management models and others like Lean, Theory of Constraints, Toyota Production System, resilience engineering, learning organizations, safety culture, human factors and many others like Agile to the IT value stream.

Lets discuss about of a few of them.

The Lean Movement

In the 1980s, techniques such as value stream mapping, kanban boards and total productive maintenance were codified for the Toyota Production System. In 1997, the Lean Enterprise Institute started researching applications of Lean to other value streams such as service industry and healthcare.

Two of Lean's central ideas are:

  1. Manufacturing lead time - the time required to convert raw materials into finished goods - is the best predictor of quality, customer satisfaction and employee happiness.
  2. The best predictor of short lead times is small batch sizes of work

The objectives of Lean principles are:

  • Create value to customer through systems thinking
  • Embracing scientific thinking
  • Creating flow and pull
  • Assuring quality at the source
  • Leading with humility
  • Respecting every individual

The Agile Manifesto

The Agile Manifesto was created in 2001 at an invite-only event attended by 17 experts in what were known as lightweight methods in software development with the motive to capture the advantages of these methods and codify them into a set of values

One key principle was to: "deliver working software frequently, from a couple of weeks to a couple of months with a preference to the shorter timescale" The other values focused on the need for small, self-motivated teams working in a high-trust management model. Agile has increased the productivity and responsiveness of many development organizations. Many key DevOps moments occured in the Agile Conferences like the following:

  • At the 2008 Agile Conference in Toronto, Canada, there was a session held discussing the possibility of applying Agile principles to infrastructure (also referred to as "Agile system administration")
  • At the 2009 Velocity Conference, John Allspaw and Paul Hammond delivered the now famous "10 Deploys per Day: Dev and Ops Cooperation at Flickr" presentation in which they discussed Creating shared goals for both Dev and Ops teams AND Using continous integration practices so that deployment is part of everyone's daily work

And then Patrick Debois organized the DevOpsDays conference in Ghent, Belgium in 2009 which witnessed the coining of the term "DevOps"

The Continous Delivery Movement

Jez Humble and David Farley built upon the development discipline of continous build, test and integration by extending the concept to continous delivery which defines the role about deployment pipeline to make sure code and infrastructure are always in a deployable state and that all code checked into the source control platform can be safely deployable.

Toyota Kata

In 2009 Mike Rother wrote Toyota Kata which talked about his twenty year journey to understand and codify the Toyota Production System. Now an interesting twist, he found that the companies who adopted the Lean approach failed to replicate the performance levels at the Toyota plants. He concluded that one important practice which he called the improvement kata, was missing. It needed daily habitual practice of improvement work

In the next post, we will discuss about value stream, applying lean principles to the technology value stream and The Three Ways of Flow, Feedback and Continous Learning and Experimentation.

Did you find this article valuable?

Support Jaison by becoming a sponsor. Any amount is appreciated!