Knowledge Base / Where does Scrum come from?
Lean and the Toyota System
Scrum is founded on empiricism and lean thinking. Scrum Guide (SCHWABER; SUTERLAND, 2020).
What is Lean?
The Toyota Production System (TPS) was created in the 1950s by the Toyota Motor Corporation in Japan, with the ambitious mission of competing against US giants Ford and General Electric (GE). These companies dominated the world market at that time, producing automobiles as cheaply as possible based on mass production.
However, in post-war Japan, with a devastated economy and a very limited domestic market, Toyota needed alternatives. The company concluded that it should produce small volumes of different models, using the same assembly line (LIKER, 2003; WOMACK et al., 1990).
In the 1990s, through their books the American authors James P. Womack and Daniel T. Jones disseminated the Toyota Production System to the world. The Japanese system was generalized and renamed as Lean Production, with the justification that it uses smaller amounts of everything compared to mass production. The term Lean Thinking was also coined to extend these manufacturing concepts to business in general (WOMACK; JONES, 1996; WOMACK et al., 1990).
In following sections, however, I take the liberty of calling the Toyota Production System, Lean Production and Lean Thinking just “Lean,” except where I intend to make some distinction between them.
The Agile and Lean propositions are different. While Lean was originally conceived for industrial work, Agile was created in the context of software development and later extended to other areas of creative work. Nevertheless, Lean is pointed out by several authors as a source of inspiration for a significant part of their Agile and Scrum ideas (COCKBURN, 2007; HIGHSMITH, 2004). As we will see further ahead in Lean and Agile, they indeed have various commonalities.
The principles of Lean
The five principles of Lean are:
- Define value – Specify what value means from the perspective of your customers, not the producer. In other words, the product is created to meet the customer’s needs.
- Identify the value chain – For each product (or family of products), identify all the steps that need to be taken so that we can offer customers the final product. Steps that do not generate value for customers and that are not identified as necessary constitute waste and will be eliminated.
- Create flow – Steps that generate value flow continuously, without interruptions or boundaries between departments, or between the organization and suppliers.
- Establish “pull” production – End products are generated based on the customer’s needs and released when they need them. Production, therefore, is not “pushed” by the producer, but “pulled” by the customers. Each step in the value chain “pulls” from the previous step only what is necessary and when it is needed.
- Pursue perfection – The organization always pursues perfection, eliminating waste, learning and continually improving its processes.
Lean and Agile
To help the reader understand the influences of Lean on Agile, I draw a parallel between the principles of both, as well as highlighting how Scrum addresses them.
Define value
In Lean, the customer is treated as an integral part of the production process. Value is defined from the perspective of that customer, in order to meet their needs. The product they want is produced and released when they need it.
The Agile Value customer collaboration over contract negotiation and the Agile Principle business people and developers must work together daily throughout the project establish that the customer’s contribution to the production of value is essential for the success of the work.
In Scrum, the Product Owner is primarily responsible for frequent interactions with the customers and users and incrementally defining a product that gives them value. The Product Owner orders the work based on the features that she believes will generate the most value for these customers and users. Frequent releases are made, feedback is obtained on each development cycle and each release, and the product is adjusted accordingly.
Identify the value chain
The steps in production that do not generate value for customers constitute waste – called muda, in Japanese – and we must seek to eliminate them. Avoiding waste, one of the main concerns of Lean, permeates virtually all the Agile Values and Principles.
In particular, the Agile Principle simplicity – the art of maximizing the amount of work not done – is essential advocates the reduction of waste through the application of simplicity; that is, the generation, either as an accessory or as a product of the work, of only that which is really necessary and sufficient. We can define the value chain in Scrum as all the activities performed so that we can offer customers one or more done Increments of the product at the end of a development cycle (Sprint), according to the Definition of Done. Among these activities, those that do not add value to the product are considered waste.
Notwithstanding, they may still be necessary or unavoidable. These activities may not have been able to be eliminated, at least at that moment. They are called type 1 muda in Lean. Bureaucratic documentation required by contract are examples of this type of waste. Activities that are wasteful and unnecessary should be eliminated immediately. These are called type 2 muda in Lean.
The team always works on the highest order items at any given moment, those that are most important to the realization of the goal. Thus, when they reach a given deadline – a release date or even the end of a Sprint –, the highest-order items will be done, eventually leaving only the items that are least important for the goal. The order of these items is continually reviewed and updated based on the customers and users’ feedback on what has been produced, ensuring that the implementation of items of little importance to the goal is delayed and often not carried out, which helps to prevent waste.
The agile practices of scheduled meetings and frequent releases maximize communication within the team and between team members and customers, thus allowing for frequent inspections of work processes and the product under construction. Hence, based on the feedback obtained from these inspections, we seek to adapt the processes and the product with improvements, which helps reduce waste. Another important point is the valuing of individuals and their interactions more than processes and tools, as the excessive use of tools and complex processes can generate waste.
The Agile Principle working software (or product) is the primary measure of progress is a response to one of the great sources of waste in product development, which is the generation of features or artifacts (such as documents, plans and reports) that do not create any value for customers.
We can also say that the Agile Principle continuous attention to technical excellence and good design enhances agility aims to reduce waste by seeking to avoid products that are poorly designed and made by individuals without the necessary knowledge and skills.
Create flow and establish “pull” production
Lean establishes that the steps necessary for generating value must flow continuously, one after the other, without stops, queues, accumulation in batches or barriers between departments. In order to release to customers what they need and when they need it, production is “pulled” from their needs, with each step then “pulling” from the previous one in the value chain. This is called just-in-time or JIT.
Unlike the batch system, where each process step produces one batch of items and “pushes” them to the next, in JIT each step produces only what is needed to supply what was requisitioned by the next, thereby reducing inventories.
Similarly, when developing a product with Scrum, done Increments of the product are implemented by cross-functional teams in short iterations, one after the other, that aim for frequent releases. The Increments are released to meet the customers’ most important business needs at any given time, and defining what to produce is an ongoing work of interaction between the Product Owner and Developers of the product with the customers and their users.
Kanban (a word that means “signaling” in Japanese) is a Lean system used to help create flow using visibility. Operators use visual signals in the production flow to determine that an action should be taken – for example, replenishing a certain number of parts that serve as inputs to a process.
Common visual signals in this system are cue cards with different colors (and meanings), and even empty containers, indicating they must be refilled (GROSS; MCINNIS, 2003). We should not confuse kanban with Kanban (with a capital “K”), a Lean-based method created for managing knowledge work.
The Sprint Backlog in Scrum is often represented in the form of a task board. Although not a kanban, this board reflects some of its aspects, creating some transparency about the team’s workflow.
In addition to muda (no value addition), two important categories of waste must be equally avoided. These were not observed by Lean Production but are an integral part of the Toyota Production System (LIKER, 2003).
The first category is muri, defined as an overload on people or equipment beyond their natural limits, in a way that can result in safety, health, reduced lifespan and quality problems, for example. The other category of waste is mura, defined as irregularities, fluctuations, or imbalances in the pace of production. These occur because internal problems – such as bottlenecks in the production flow, defective or missing components – or maintenance problems mean that at times there is more work than the people or machines can do, and at other times there is a lack of work (LIKER, 2003).
An incorrect interpretation of Lean leads it to being used to intensify work to a point where worker burnout can become a serious problem, threatening the entire production system. For this reason, Lean has even been called “management by stress” (HAMPSON, 1999).
According to this interpretation, managers increase pressure on the production system beyond its capacity, reducing resources and deadlines or increasing the amount of work, for example. The idea is that, in this way, the stress generated in workers and machines causes the system to fragment, and thus allows for the identification of points for improvement and restructuring. It is also intended to force the use of creativity, self-regulation, and teamwork to solve the problems arising from this increased pressure, making it possible to execute the same amount of work with fewer resources.
This type of approach leads such companies to practice the muri waste (overloading people or equipment beyond their natural limits) and mura waste (imbalances in the pace of production) mentioned above, and in that way face the resulting problems.
To combat these wastes, the Toyota Production System brings the concept of heijunka (or “leveling”, in Japanese), fundamental and essential to the establishment of continuous flow, but often forgotten by the advocates of Lean Production. Heijunka is obtained from balancing and leveling the production flow, avoiding the formation of bottlenecks, and leading to constant and sustainable production paces and levels.
In this sense, by practicing heijunka, mura is automatically eliminated (LIKER, 2003). Moreover, heijunka can only be accomplished within the normal capabilities of the process, workers and machines, thus also avoiding muri (HAMPSON, 1999).
In product development it is common for management to force an accelerated and eventually unsustainable pace of work for the teams, especially at critical moments, such as before a release date. This behavior mainly results in practices such as overtime and reduced quality.
It is also common for Scrum to be incorrectly used for this purpose, and which can be accentuated by some characteristics of the framework, such as high transparency about the work and short cycles, with the consequent possibility of a high frequency of releases. Notwithstanding, production carried out at a steady and sustainable pace is essential for working with Scrum, and is defended by the Agile Principle: agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Thus with the practice of Scrum, we understand that we should seek a balance of the workflow similar to heijunka, so as to avoid muri and mura waste. Scrum has some mechanisms that, in a simplified fashion, aim to achieve this balance. Among them, we can highlight:
- The Sprint, which is a development cycle that is repeated in format throughout the work and always has the same duration. This fixed and constant duration helps establish a regular pace of work for the Developers of the product, a cadence that the Scrum Team, customers, and other stakeholders get used to, becoming accustomed to how often they will see the results of the work and offer feedback.
- The ordered work, cross-functionality and accountability for the results shared among the Developers. They have, among themselves, all the knowledge and skills necessary to develop the product. At the same time, despite this knowledge and these skills being distributed differently among the different Developers – there may be, for example, specialists – the accountability for each task belongs to everyone. By working from an ordered list, a particular Developer, instead of opening a new work item of a lower order that has tasks within their area of knowledge, will seek to assist the other Developers in completing higher-order work items, even if outside their area of knowledge. In this way, this knowledge is better distributed among the Developers and production bottlenecks are progressively eliminated.
Lean also brings the concept of jidoka, which means “automation with a human touch” in Japanese. Jidoka establishes that the workers themselves must conduct the quality control, immediately stopping production if any defect is found in order to seek the root cause, solve it and prevent the problem from happening again. Quality is therefore embedded in the production process itself.
Likewise, cross-functional Scrum teams are also accountable for product quality. This accountability means that the ability to test or guarantee quality lies within the team itself, there are no external quality teams.
Pursue perfection
Kaizen (“change for the better” in Japanese) is the pursuit of perfection through infinite and frequent steps of continuous improvement, an essential practice of Lean. One of the keys to making kaizen possible is hansei, which means “deep reflection” in Japanese.
Hansei is a relentless and mandatory self-reflection used to identify and recognize mistakes made or improvements that need to be implemented so we can create an action plan that puts the improvements into practice. Hansei is based on the belief that there is always something that can be improved. Its goal is never to point blame, but to make problems visible in order to help the team make improvements (LIKER, 2003).
In Agile, continuous improvement is expressed in the Agile Principle at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. One of the important continuous improvement mechanisms in Scrum is the Sprint Retrospective meeting, which is basically the application of hansei.
Definition: The Five Whys
To discover the roots of any problems, we can make use of a tool in Lean called The Five Whys. In this technique, once a problem occurs, we ask “why?” iteratively five times, always questioning the previous answer. We initially ask the reason for the problem and arrive at an immediate cause. This cause is questioned again by asking “why?”, so that we get another cause, which is in turn questioned again, and so on, until we have asked “why?” five times, when we then assume to have gotten to the root of the problem. Based on that, we propose improvement actions (LIKER, 2003; OSONO et al., 2008).
This technique can be used by agile teams, since discovering the root cause of problems and then solving them is an essential practice of Agile, in which we seek to avoid waste and make continuous improvements.