Scrum & The Toyota Production System, Build Ultra-Powerful Teams

According to Toyota, it is the employees and not the systems that give birth to the best products. It is not possible to make good products without developing the skills of employees. For this, Toyota has built a production system whose purpose is the development of exceptional employees: the Toyota Production System (TPS).

Jeff Sutherland and Ken Schwaber relied partly on the TPS to build the Scrum framework, a framework for developing complex products or services.

Scrum: the origins

The origins of Scrum can be traced back to a founding article published in Harvard Business Review in 1986 by Mr. Hirotaka Takeuchi, Harvard Business School Professor, and Mr. Ikojiru Nonaka, Emeritus Professor, Hitotsubashi University, Tokyo, entitled The New New Product Development Game.

In 1993, based on this article and on the principles of lean manufacturing, Jeff Sutherland, develops a radically different method for the development of computer products. In 1995, with the help of Ken Schwaber, he formalized the method: Scrum was born. 

Scrum is a rhythmic planning method. It is opposed to the traditional batch type approach considering that the construction of a computer system requires to have first completed its analysis before proceeding to the development then the tests. This very cumbersome and costly approach has left many projects deadlocked.

On the contrary, Scrum breaks this model by cutting out the construction of the product in small batches called sprints. During a sprint, the team analyzes, develops and tests what the client considers most valuable to him. A sprint lasts between 1 to 4 weeks. At the end of the sprint, during the sprint review, an increment of the product is presented to the customer who can thus quickly provide his feedback. The team corrects and adapts the product sprint after sprint and according to customer. Gradually the product takes shape. In addition to this ongoing adaptation to customer needs, Scrum provides a formal structure for improving team practices by introducing the notion of retrospective. It's a special moment at the end of the sprint during which the team looks back on its practices to improve them in the next sprint.

Scrum, the Toyota Way and the Toyota Production System

If we look at Scrum from the lean angle, it's clear that the method has its roots in the Toyota Way and the Toyota Production System.

[Click on the image to enlarge it]

Figure 1 - The Toyota Way

From the point of view of the Toyota Way, continuous improvement and respect for people are clearly represented. The very structure of Scrum is a problem-solving meta-structure that has the structure of a Plan Do Check Act (PDCA) as defined by Deming. The Plan with the sprint planning, the Do with sprint, the Check with the sprint review and the demonstration to the client and the Act with the retrospective. This learning loop is continuously repeated throughout the product construction and helps to understand customer needs, individual development and teamwork.

Scrum also relies on certain principles of the Toyota Production System, especially Visual Management and Just In Time. At the end of the sprint schedule, the team has a backlog of user stories that it makes visible by relying on a Todo / Wip / Done or Kanban visual management type. The team's performance is measured by its ability to deliver all user stories at the end of the sprint through a burn down chart indicator. Each sprint is a "Time Box" of one month or less during which a "Completed", usable and potentially publishable product increment is created (see Scrum Guide). The construction of the product is divided into small batches whose delivery is timed at a steady pace, it is the concept of Takt found in the Just In Time pillar of TPS.

Nigel THURLOW, Chief Agile Officer at Toyota Connected, demonstrates this brilliantly in his formidable training Scrum The Toyota Way. However, I think it is possible to go even further. If Scrum is a great planning tool, it is also, as Jeff Sutherland says, a container for other techniques, methods and practices. And in this sense, a perfect framework for the development of people sine qua non for the production of Wahoo products. Indeed, the different experiences that I lead since discovering lean in 2008 with Marie-Pia IGNACE and Michael BALLE show that a rigorous implementation of the Toyota Production System within the sprint brings exceptional results in terms of learning and a fortiori production.

[Click on the image to enlarge it]

Figure 2 - The Toyota Production System

The question that arises is how to implement the tools of the Toyota Production System to achieve each increment of the product, to reveal in real time, the obstacles that the team faces every day and give it the means to solve them.

The TPS must be considered as a scaffolding whose purpose is to make the problems visible at the moment they appear. We must first build the system and then make it work:

1. Build good visual management
2. Pull the stream
3. Identify the right problems
4. Solve problems
5. Draw the right lessons

Build the right visual management

[Click on the image to enlarge it]

Figure 3 - Visual Management example

Everything starts from there. It is fundamental to have a good visual management to progress and it should allow to distinguish what is ok from what is not. Is the team delivering at the right pace with the right level of quality? Does the team spend time correcting anomalies or bugs? Are user stories blocked from awaiting information from other teams or awaiting the availability of a test environment? At a glance it must be possible to see if the situation is under control or not and whether the overall performance of the team is improving or not. Good visual management must include 4 panels: a client wall to capture customer incidents, a performance panel with quality, time, cost, productivity indicators, a production panel and finally a panel dedicated to problem solving.

Pull the flow

The implementation of the Just In Time within the sprint starts with the calculation of the Takt. As Scrum sets the pace of product construction on a macro level, it is important to set a production rhythm within the sprint, to develop user stories at a steady pace. The calculation of the Takt is simply a matter of dividing the number of stories by the number of working days in a sprint: 20 user stories for a 10-day sprint gives a delivery rate of 2 user stories per day. And then put the production in pull flow. That is, put yourself at the end of the process and pull the user stories starting with the ones closest to the exit. The daily objective is defined by the Takt. In our example, the team chose 2 user stories, starting with those located at the stage closest to production. The team commits daily to a production goal: in this case 2 user stories selected from the ones closest to the exit of the process every day. If the team reaches the goal it is perfect, if it does not happen it is even better: there is something to learn, it is a new opportunity to improve and thus to make kaizen.

Identify the right problems

See quality issues

If the principle of small-batch cutting is rather well exploited by Scrum, the Jidoka, the second pillar of the TPS is much less so. Jidoka is about introducing quality into the process so that it does not propagate quality issues along the process down to the customer. Several techniques such as stop at the first defect, autonomation, red bins, andon allow to discover non-quality problems before they spread in production and penalize users of the application or service.

The most advanced teams use extreme programming techniques such as Test Driven Development and Continuous Integration to implement parts of the Jidoka. However not all teams have the level of competence required to implement these techniques which, moreover, do not cover the whole process. The question that arises is how to identify quality problems in the process, regardless of the level of mastery of these practices? One answer is the introduction, at every stage of the production process, of the red bins lean technique.

[Click on the image to enlarge it]

Figure 4 - See quality issues

Whenever a quality problem is discovered at one stage of the process the information is stored in the red bin. Rigorous and systematic analysis of its content allows the team to better understand what is blocking the flow and trigger immediate action to protect the customer and the problem solving needed in the longer term to permanently remove these obstacles.

 Figure 5 - Red bin example

See flow issues

The use of the pull flow highlights a series of problems related to the dynamics of the development process: overload and overproduction problems or synchronization with other processes as shown in the figure below.

[Click on the image to enlarge it]

 Figure 6 - See flow issues

Problem solving

The only purpose of what is described above is to create a scaffold to highlight what the team does not control. Thus, the implementation of the pull flow and the Jidoka will reveal on the visual management different sources of problems:

• quality problems that are found in red bins and that are mainly an expression of a lack of skills,
• synchronization with other flows when user stories are pending in the work in progress column,
• overproduction or overload problems when user stories pile up in a ready or running column.

By making these obstacles visible in real time, the team has very short feedback loops that allow them to react extremely quickly to put the defective user stories back into the stream (correction = client protection). The team can then take a step back to deal with the problem definitively (resolution = permanent elimination of the problem). To do so, lean advocates a scientific approach to problem solving with the PDCA (Plan Do Check Act).

[Click on the image to enlarge it]

Figure 7 - PDCA example

The whole point of the method lies in the accumulation of learning opportunities and in a conscious process of problem solving. Employees do not succeed by coincidence, but by a systematic analysis of problems, the search for root causes, the implementation of adequate countermeasures, their testing and a capitalization on what the team has learnt. This repeated activity is a tremendous accelerator of individual and collective performance. The treatment of red bins makes it possible to precisely identify the causes of the quality problems that most often arise from skill problems. This is an opportunity for the Scrum Master or Team Leader to set up skill matrices and training dojos to work on specific gestures, such as writing more relevant user stories or a cleaner code.

Figure 8 - Competences matrix example

The analysis of the flow, the overproduction and the waiting time provides a better understanding of project or product adhesions with the rest of the ecosystem. Team members build intensive collaboration not only within their team but more importantly with their counterparts working on related topics. Problem solving is no longer an individual affair but a matter of teams in the broad sense. Little by little, the whole organization works better. Processes are simplified as improvements are made collectively.

The results

Out of 20 teams observed, who applied the methodology, we measured a very significant improvement in performance.

Improving the quality of production

Thus, in the field of quality, stocks of unprocessed incidents decreased on average by 59%. At the same time the volumes of new incidents dropped by 37%. This resulted in an average increase in customer satisfaction of 25%.

Figure 9 - Quality improvement

Acceleration of value production

Whether in the resolution of incidents, the development of small changes or the realization of new user stories, acceleration is also remarkable. The lead time is divided on average by 6.5 and the production is multiplied by 3.

Figure 10 - Acceleration of value production

Economic impact

For example, in a business unit of 40 people, the equivalent of 5 employees is in charge of fixing incidents. On an experimental basis, the manager decides to create a team dedicated to the reduction of incidents. In 6 months, this new team, thanks to the implementation of TPS, eradicates the incidents and passes from a permanent stock of 80 incidents and a daily volume of 3 new incidents to a stock of 0 and a monthly volume of 2 new incidents. The cost of resolving incidents collapses. It goes from 720 000 € per year to 0 € (5 people * 600 € * 240 days). In six months, the manager has earned more than half a million euros from his RUN budget _without counting the savings triggered by quality improvement_ that he can reallocate to value production. This gain in productivity allows to accelerate the processing of the small changes backlog and thereby producing more value for its customers. 

Conclusion

The aim of the lean management system is to develop outstanding employees to produce exceptional products. Toyota's Production System, TPS, is a set of practices whose sole purpose is to highlight the weaknesses of the process so that employees can solve them by developing their skills. Scrum is the implementation of Just In Time for computer system production. The method cadences the construction of the system through a series of increments that have the form of PDCA: (Plan) Sprint planning, (Do) the sprint, (Check) the sprint review, (Act) the retrospective.

However, the application of the TPS must not stop there. At each stage of the process, employees can progress individually or collectively throughout the entire production chain, be it the Product Owner, developers, architects or testers. It is therefore fundamental for the development of everyone to have a system that reveals problems where they arise, in real time to give them the opportunity to improve the situation: their skills, the process or the interaction between different services.

The TPS offers the necessary tools for this:

• the visual management at the condition it shows the different steps of the process,
• the pull flow that gives a rhythm to the production and allows immediate feedback on the ability to meet deadlines,
• the red bins that provide immediate feedback on the quality of what is produced.

With this system, the teams focus on the operational issues that prevent them from achieving their daily goal. Team members develop their skills, solve problems after problems, thanks to a rigorous scientific analysis method. Each PDCA brings them closer to a production ideal in which all user stories go through the manufacturing process smoothly to production. The implementation of Jidoka reveals quality issues that are usually related to skill issues. The Just In Time shows the flow problems and the adhesions with the rest of the system which triggers problem solving between teams.

Little by little user stories are better described, their size decreases, the developers produce a code of better quality, more maintainable, more robust, more reliable. Integrators find fewer defects and have more time to focus on boundary testing or automation. Collaborative work with other teams simplifies the system and streamlines exchanges. The team develops new skills and adopts new practices. The capacity of the team increases as quality improves, production speeds up, costs decrease. The customer smiles :-)

About the Author

Pierre Jannez is a Lean IT Senior coach specialized in improving the performance of IT teams. He was interested in agile practices from 2001 and deployed them for ten years at Nokia then Nokia Siemens Networks within the French development team: extrem programming, TDD, continuous integration, BDD, continuous delivery, Scrum. In 2008, he and his team discover lean. The first applications give immediate results, quality and lead times improve significantly. Since 2010, he has been dedicated to the application of the Toyota Production System in the field of IT within the firm Operae Partners.