Toyota Production System – the Foundation of Scrum
The Toyota Production System (TPS) is the cornerstone of Lean Management. It is best described as: “an Operations Management System to achieve goals of the highest quality, lowest cost and the shortest lead-time via engaging people towards goals.”
Ironically, although lean is considered a Japanese management technique (and indeed Toyota has done more than any other company to promote it as a pragmatic philosophy) it is actually based ophy on the principles of Henry Ford (“today and Tomorrow”, 1926). Toyota’s founders (Sakichi and Kiichiro Toyoda) were unable to follow the mass-production model advocated by Ford owing to the lack of volume demand in post-war Japan, and so they emphasized continuous flow (at the expense of batch assembly) to reduce waste. This is the underpining of what we now understand as ‘lean manufacturing’, which has at its core the elimination of waste as a central tenant.
Ford claimed that his factories did not build cars, it built people, who built cars, and this philosophy obviously sat well with the Japanese culturally. Without a long term commitment to its employees, continuous improvement could easily become ‘continuous lay-offs’ as productivity increased, and this is one of the least understood underpinings of successful implementation.
In “The Toyota Way” (Jeffrey Liker, 2004) stresses that the TPS is suited only for manufacturing processes, and then only really those that are highly repetetive. In the last section of the book several examples from service-orientated businesses are given (shipbuilding and a post-office) but in all cases there is a strong unidirectional process involved (i.e. sorting mail).
Scrum is a ‘lean’ project management technique optimized for software development (but with larger applicability). It incorporates many of the core elements of TPS, and one can say that Srum is an extremely clever and ingenious adaptation of TPS to barely-repeatable projects – an area of human activity that lean manufacturing never considered possible.
Lean Essentials- Muda, Mura, Muri
The three evils are batching (uneven production) [muda], waste [mura], and overworking [muri]. Ford gives us the oringal seven forms of waste:
- Over Production
- Over Processing
- Excess Walking / Movement
- Transportation & Conveyance
- Excess Inventory
Toyota adds another that would probably have never occured to a turn of the century industralist, which is (8). unutilized creativity. Ford also gives us the five commands of cleanliness, which are encouraged with TPS – tidy desk. tidy mind!
- Sort and organize what you need, and discard everything else
- Straighten – a place for everything, and everything in its place
- Shine – by keeping the workplace clean, waste can easily be detected
- Standardize – create rules and systems. However, standards should be constantly innovated and improved upon and should not be regarded as static. Most importantly, workers should not be penalised for increasing productivity
- Sustain – this is an ongoing effort to which management needs to commit.
The Toyota Production System is not just a collection of tools and techniques, but rather an interlocking set of principles which form a cultural framework. The framework is based around people – Toyota is one company that truly believes that its main assets are its people, and it tries to grow that asset deliberately. Management, Techology and Philosphy all combine to assist in the growth of its people.
Jeffrey Liker identifies 15 practices which underpin TPS, of which Scrum has selectively picked seven to adapt to the software development cycle.
Decide on metrics that are really important, and elminate all those that are superflous or that drive behaviors that are contrary to the desired ‘lean’ future state of the process.
Chief Engineer is the person who is ultimately in charge of the car – each car at Toyota is led by one Cheif Engineer. In Scrum, this role is filled by Product Master
|Batching||Just as batching is anathema to TPS as it creates waste and unlevel production, so a waterfall development cycle is anathema to Scrum as it creates work which may easily become redundant|
|Takt||Takt is the average pace of customer demand. For example, if a car is being ordered every 53 seconds, then a car needs to be built every 53 seconds. Therefore in a continuous-flow process, every individual step needs to take exactly 53 seconds. There is no exact comparison within Scrum. However, the speed of development must be such that eventually the backlog is completed. Rhythm is artifically injected into the process through sprints and the daily stand-up.|
|Jidoka||Jidoka is the automation of processes that automatically interupt the process, or are designed such that quality is built in, not inspected in. Scrum uses automated testing, and test driven development where possible to emulated jidoka.|
|Hiejunka||Heijunka is the levelling of the production load so that a steady pace can be achieved (supporting Takt). It is embrassed in Scrum through the deliberate enforcement of a standardised timebox (the Sprint) for development.|
|Muri||Muri is overworking. Overwork causes burn-out and is not good for the employee, nor ultimately the company and society, and is therefore discouraged. The desired paradigm is the tortoise, not the hare Scrum similarly discourages death marches and unsustainable effort. The development team should be working at a steady pace which is indefinitely sustainable.|
|Kanban||Kanban are the component control cards that flow through a Toyota factory along with the parts that they represent. They are a tangible representation of the part, and are used to instigate the pull process which draws parts through the system. Scrum’s equivalent is the story ‘stickie’. Within scrum, each component of the solution (each ‘story’) is written on a stickie, and the stickie is then used to represent the evolution of the work as it progresses from in design, to in development, to completed.|
|Andon||Andon are the alerts and visual process control systems that allow workers to quickly see where a process is out of control, and to, when necessary, halt production in order to fix the situation at source.|
|Team Leaders||TPS team leaders are an overhead that float above the work of their team, anticipating and solving problems, and filling in for absentees etc. They are the ScrumMasters.|
|Hansei||Hansei is the Japanese term for honest and relentless reflection (culturally similar to the ‘time-out’ American children get). It is the process of looking at oneself and seeing where improvement can be made, and is the first step in making that improvement. Scrum retrospectives, held at the end of every sprint, are opportunities for Hansei.|
|Obeya||“The Big Room” is a technique first used by Toyota on the Prius development. The colocation of the team into a ‘war room’ proved so successful that it is now part of the standard techniques used for new or incremental development is undertaken. Scrum strongly encourages both the colocation of the team and the designation of a team war-room where all the visual controls and systems are on display.|
|Genchi Genbutsu||Go and see for yourself, and not rely on management reports or other third hand mechanisms is reflected in Scrum’s pervasive emphasis on working software over documentation|
|Sense of Urgency||TPS generates a sense of immediacy and urgency through the use of continuous flow. Unlike a batched process system, if there is any problem within any part of the process, the whole process is liable to come to a screeching halt. This is an intrinsic instability of TPS, and is actually encouraged and built in where possible (and the cost of interuption is not massively severe). By generating this sense of continual urgency and vitality, workers are kept motivated and problems are solved quickly.|
Continuous improvement (innovating standards) is really, really difficult…”Capturing knwledge is not difficult. The hard part is getting people to use the knowlede and to contribute to it”. People need to constantly trained and encouraged from the very first day. Among the organisational assets utilised is a know-how database which preserves both good and bad design paradigms, and everyone is encouraged to both draw from and to contribute to this store of corporate knowledge.
Processes need to be benchmarked before they can be improved, and one of the main tools for this benchmarking is the Value-Stream Analysis. This is a swim-lane flow chart concentrating on value-added processes. Metrics tracked on this chart are total task times, the time that the work unit is in the system, and the ration of value added to total task time. The correct identification of hte customer(s) is a vitally important first step when approaching value-stream analysis, as value-added is always in relationship to the customer.
Motivation is achieved through the creation of challenging targets (stretch goals), constant measurement and immediate feedback, with the occasional reward. The motivational framework is therefore very similar to that found in successful games. It is interesting to note that objective-setting also plays an extremely important part of the motivation.
…on Strategic Alignment
Strategic Plociy Deployment (Hoslin Kanri) starts with high level objectives, and then cascades these down to every level in the organisation – the high level strategy is translated into quantitative, achievable objectives.
…on IT & Automation
“Measuring isn’t Controlling”, and technology is not a subsititute for a good process. First the manual process should be perfected, and only then should it be automated, becuase it is very easy to kaizen people-based processes, but it is much more difficult to continuously improve machines. Technology should be surgically inserted into an already finely tuned and working process, rather than implemented as a panacea on a process which does not work properly. Also, there should not be a 100% reliance on technology and tools. Go and See is a good example of this in action, and any computer-based analysis of the situation should be complemented with manual, empirical analysis. Where possible technology solutions should be pulled and not pushed. – the IT department should never be allowed to impose a technology on an operating division –