What I Learned at Toyota

Test driving the new Toyota hydrogen powered Mirai with Pierre Masai

I first met Pierre Masai, CIO of Toyota Motors Europe (TME), a few years ago at the annual Lean IT conference in Paris. Pierre is an agile advocate committed to driving Scrum across the IT infrastructure. At his invitation I recently spent most of two days in Brussels meeting with managers and developers and presenting some of what we have learned about Scrum. I decided to begin by asking how Toyota addresses the three mega challenges we identify in our Scrum trainings and Scrum@Scale workshops:

1. Does the company have a clear product backlog for every team every sprint?
2. Can the company get to Done with useful features by the end of every sprint and does Done mean deployable? ­­­
3. Can the company easily refactor its organization to take advantage of market conditions and optimize delivery of valuable product to customers? Small, cross functional teams supported by management are essential.

Just like every company transitioning from traditional product development to an agile way of working, Toyota wrestles with these challenges. They too need clearly visible priorities. They too find instances where everything is priority number one and where people work on many different things at once. This produces a lot of waste. In companies where many things are top priority and everyone is working on many things at once, multitasking is the norm. As Gerry Weinberg showed in Quality Software Management: Systems Thinking, people or teams working on five things at once have a 75% loss due to context switching. It seems the larger the company, the worse this problem is. At the team level it makes it difficult to get things Done at the end of a sprint. Process efficiency is terrible. They too need a more rigorous definition of DONE so that useful features are deployable at the end of every sprint. All testing needs to be done within the sprint. All bugs need to be fixed within the Sprint. It takes much more time to fix a bug weeks later, for complex products as much as 24 times longer to test and fix. And, not all of their teams as are as small or as cross functional as they could be. However, Toyota has distinct advantages that most companies do not have when making an agile transition. Toyota has a heritage of excellence built upon the Toyota Product System and the discipline of Hoshin, a system of strategic planning that:

1. Selects a key objective.
2. Aligns implementation plans at all levels.
3. Implements, reviews, and improves the plan on an ongoing basis.

As Toyota increases the rigor of the Hoshin system, more people do more valuable work. They expect things to get Done in short iterations, ideally single-piece continuous flow. Taiichi Ohno set up the Toyota Product System to use small cross-functional teams that radically improve process efficiency. The net result is that Toyota's per-car profits lap Detroit's Big 3 automakers. Unfortunately, Toyota has historically implemented traditional waterfall project management in IT. When I reminded them of their heritage and asked what Taiichi Ohno would say if he looked at the remnants of the waterfall process that still exist today at Toyota, they said "He would be outraged!" So what I learned at Toyota is that Hoshin and the wrath of the founder are powerful incentives to get Toyota IT agile. -- Jeff Sutherland

Note:  The process of hoshin planning follows Deming's Plan-Do-Check-Act  cycle. PDCA is a generic method for continuous improvement, which is what hoshin planning aims to be. Scrum is based on Deming's PDCA cycle and on Takeuchi and Nonaka's new product development. It has Hoshin embedded in the form of a Product Owner Team that aligns the whole organization with one hierarchical product backlog. This ability to focus gets more useful work done. In Toyota’s case, it allows them to achieve superior profitability on their products which is the goal of the Product Owner in Scrum.