How Toyota Laid the Groundwork for DevOps-EN

When I was in primary school, one of my classmates asked my teacher why we had to learn about history. His answer was that it’s important to know what happened in the past because history has a pattern of repeating itself.

Looking back, I think there was so much wisdom in his answer. History really does repeats itself, so much so that if we really boiled down to it, we would see that so many of today’s “new” ideas are really just evolutions of old principles that have been cultivated and refined over time.

For example, the term DevOps is said to have first been coined at DevOpsDays Belgium in 2009. But despite our belief that a new name is synonymous with a new concept, the principles of DevOps were actually established almost 7 decades earlier.

Let’s go back to 1950’s Japan after the Second World War, when Edward Deming, Taichii Ohno, Shigeo Shingo, and Eiji Toyoda created the Toyota Production System (TPS), which gave rise to what would be called “Lean” forty years later in the book The Machine that Changed the World by Womack & Jones.

TPS is based on three fundamental principles through which people change the way they think and act:

• Quality at the Source
• Leveled Production or Just-In-Time
• Continuous Improvement

These three simple principles make up the essential elements of what is now called DevOps.

Quality at the Source (QatS)

The principle of Quality at the Source seeks to achieve correct results for each action on the first try. Focusing on ensuring quality at every step will reduce delivery times and operating costs, which are essential to DevOps’s goal of rapidly delivering quality software to the business. This involves integrating tests into development, and even goes so far as to change the way you program to what is called Extreme Programming.

This seemingly counter-intuitive method involves developing the test case before developing the piece of code you’re testing. That way, the code development is oriented around the expected results of the test. In other words, through Extreme Programming, you can change the way a developer thinks and acts to look for quality at the source and integrate testing into development.

Therefore, DevOps continuous integration systems (including the integration and automation of unit testing, along with regression, integration, and even acceptance and static code analysis) are a fundamental implementation of Quality at the Source.

But there is more. Let’s say you have a DevOps team who, at the end of the development day, launches the scripts that automate the testing and generation of builds. Then the next day, they visualize the quality level of the code, its technical debt, and test failures in order to plan their resolution the same day. That team is applying Jidoka, an essential aspect of TPS Quality at The Source: defects are visible, and everyone can see what is defective and take responsibility for their resolution. 

Let’s take a look at another example: a DevOps team sees that the technical debt is higher than what is allowed, so they regroup the same day to refactor the code and ensure future maintainability. In this way, the team is applying the Andom mechanism of stopping the production chain to ensure Quality at the Source instead of continuing to produce if the defect level is higher than permitted.

Just in Time (JIT)

The second of the fundamental principles of TPS is Just in Time. According to this principle, all steps in the production chain are leveled (aligned) to the rate of customer demand, avoiding steps that over-produce or are bottlenecks where inventory will accumulate. This causes the WIP levels to be higher than tolerable and wasting unnecessary time and money.

One of the essential aspects to ensure Just in Time is the application of the WIP Cap, which puts a limit on the amount of work-in-progress within the value chain. This reduces inventory levels and controls the entry of work units, ensuring that each step in the chain is leveled with the pace of demand. Overall, the WIP Cap changes the way people think and act to focus on completing the work-in-progress before moving on to new work units.

DevOps teams implement agile methods to level the production rhythm with the pace of the business. They plan sprints with specified durations and form a sprint stack tailored to the business priorities and the estimated capacity of the DevOps team. This requires input from a Product Owner, who ensures proper demand management and manages business priorities. 

All this is possible because DevOps teams reduce the batch size to work with atomic work units that deliver value to the business, thus applying the Lean principle of batch size reduction to ensure proper leveling and, ultimately, integrating the change into the day-to-day of the teams.

Both agile methods and DevOps use batch size reduction and the WIP Cap to enable level production and ensure Single Piece Flow, an essential piece of TPS DNA.

Another aspect of Just in Time that is incorporated into DevOps is the need to reduce inflexibility and, therefore, the interruption of flow due to the lack of necessary skills and knowledge within the team. A DevOps team works with S&K matrices, used in TPS and Lean, to balance team members’ skills and knowledge with customer demand, achieving multiskilled teams capable of absorbing peaks and valleys in demand by working as a leveled system.

DevOps incorporates the TPS principle of Just in Time based on leveling work capacity and skills with customer demand. Each member within the DevOps team changes their way of thinking and acting by incorporating Systems Thinking, where everyone takes responsibility for their work and thinks about the system, works for the system, and pursues leveling, collaboration, and communication with the rest of the system members (DevOps team) with whom they share the challenge of delivering quality software to the business quickly.

Continuous Improvement

To complete our study, we cannot fail to point out how continuous improvement through daily learning, an essential behavior of TPS, is an inherent part of DevOps teams. Because of daily visual management, teams are capable of seeing and learning from their mistakes and dedicating time to retrospectives that will allow them to adjust work estimation methods, change the tools being used, learn to identify and eliminate waste, increase process efficiency, reduce defect levels, and reach challenging high-performance heights capable of delivering value to the business quickly and as-needed.

Daily learning is a quality that distinguishes a TPS production system. To learn, the team must think and act so that collective learning based on communication, collaboration, and visual management tools will help improve their day-to-day life and increase customer satisfaction.

Leadership will be an essential piece to create an environment of trust and commitment. An open environment encourages teams to change their mindset and behavior and supports the daily commitment to continuous improvement, waste reduction, and sustainable adjustment of the system.

History Repeats Itself

The current circumstances are unique – our sector is in a moment of evolutionary change – but the principles are the same. They are simple principles, we could almost say elementary, but their significance is substantial.

Gracias,

Angel