Chapter 10. Journey

This reminds us of Alice as she wandered through Wonderland:¹

‘Would you tell me, please, which way I ought to go from here?’

‘That depends a good deal on where you want to get to,’ said the Cat.

‘I don’t much care where—’ said Alice.

‘Then it doesn’t matter which way you go,’ said the Cat.

—so long as I get somewhere’ Alice added as an explanation.

‘Oh, you’re sure to do that,’ said the Cat, ‘if you only walk long enough.’

In Chapter 7 we recommend that you start a lean initiative by answering two questions:

1. How do you create value for customers and make a profit?

2. What, exactly, is your main problem right now?

To this we add two more questions:

3. What threatens your continued existence in the future?

4. What do you really believe about people?

At the same time, the Toyota Production System became well known and widely copied. As other automakers became more efficient, Toyota’s lead as the world’s most efficient auto producer narrowed. Technical advances in vehicle features were rapidly copied—for example, as the market moved to minivans and SUV’s, most auto companies rapidly followed. Furthermore, with the rest of the world comparatively saturated with automobiles, it was clear that the future growth market would move to Asia.

In this atmosphere, Toyota developed a long-range strategy for creating a sustainable competitive advantage. That strategy, best expressed as Smart Design, Smart Production, Smart Car, centered on using information technology to make profit-generating innovations difficult to copy. During the 1990s, Toyota became a very competent information systems company.

Under the Smart Production banner, Toyota replaced the traditional single assembly line with a half dozen short lines separated by buffer stock and synchronized by software, giving it a boost in productivity that is difficult to copy. Smart Design included digitizing A3 production standards and developing a way to simulate manufacturing processes on CAD systems during the design process, greatly speeding up time to market for new cars. The Smart Car initiative prompted major investments in developing internal electronic manufacturing and embedded software capability, enabling Toyota to launch the Prius in Japan in 1999. With drive-by-wire throttle, brake, and shift controls, the surprisingly popular hybrid is truly a computer on wheels.

Toyota’s success with information technology comes as something of a surprise, since the company has a reputation for its minimalist approach to IT. While competitors built highly automated plants to reduce the labor content in vehicles, Toyota experimented with automation and didn’t find that it would pay off when the total cost was considered. While competitors invested heavily in computerized scheduling systems and cross-docking automation, Toyota felt that people should be at the center of the manufacturing process and that simple manual systems would work better. Toyota management has traditionally resisted using information systems to manage material flow and production scheduling.³ We find it remarkable that a company that has been so cautious about using information systems would become such a leader in leveraging these systems in its production processes, in its development approach, and in its products.

Institutions such as churches, armies, and universities live for centuries. Why do large companies die or get acquired so young? More importantly, how can good companies survive more than a couple of generations of management? Just to make it into the list of companies de Geus studied, a company had to be very successful. Not only had the company made it past the startup phase and the growing pains of an expanding company, it had become a large multinational corporation. And then the world changed, and many of these very successful corporations failed to adapt to the new reality.

Organizations that have become successful tend to establish their habits in the days when they are growing rapidly and there is plenty of market demand. But eventually all growth engines run out of fuel, and past success no longer points the way to future growth. At this point, the organizations that have developed the capability to learn and adapt are the ones that survive. De Geus believes it is the ability of managers to envision the future that enables them to adapt to that future before it is too late; but unfortunately, managers often develop “future-blindness,” preferring to stay on the course that has led to success in the past.

This view of future-blindness is seconded by Clayton Christensen⁵ who shows that companies that move up-market to maintain margins, leaving the less profitable down-market to their competitors, are frequently overtaken by disruptive technologies. These companies serve their current customers so well that they have little incentive to imagine a future filled with risk and low margins. We see disruptive technologies in the computer industry all the time, as smaller, faster, less power-consuming hardware replaces bigger, more profitable equipment. In software, we see inexpensive software packages replacing offerings with large per-seat fees and self-service software replacing consultant-intensive businesses. In an industry that moves as fast as ours, envisioning and being prepared to adapt to the future is a survival issue.

Toyota has a tremendous ability to learn and think in an evolutionary manner. Sakichi Toyoda counseled his son Kiichiro and nephew Eiji, “Stay ahead of the times.” In 1934 the Toyoda company added car manufacturing to loom manufacturing, even though it would take two decades for the automobiles to start paying their way. In 1958, with sales of cars at barely more than 2,000 per month, Toyota built a new factory with a capacity of 10,000 cars per month to the astonishment of both its dealers and competitors.⁶ But the factory positioned the company to lead the market as the Japanese economy expanded in the 1960s. In 1984 Toyota opened the New United Motor Manufacturing Incorporated (NUMMI) plant in Fremont California, positioning it to manufacture in the United States a year before the precipitous drop of the yen against the dollar. Toyota’s Smart strategy was initiated with the purchase of an electronics plant in 1989, well before overcapacity began to plague the Japanese market. In 1995 Toyota purchased a controlling interest in Daihatsu to strengthen its position in the Asian market. Today Toyota is focusing on environmentally sensitive cars and intelligent traffic systems as key avenues for future growth.⁷

An organization that expects to survive over the long term must consistently develop an insightful view of the future and base decisions on this long-range vision.

There are two conceptual frameworks concerning the use of technology in the workplace. The first framework suggests that we should automate existing jobs to reduce the need for people or the skill level needed to perform the job. The second framework encourages us to use technology to enhance the capability of workers.⁸ As we have seen, Toyota operates in the second framework. But what’s wrong with the first? Automating routine tasks sounds like a good idea. In fact, as we noted in Chapter 8, automating repetitive tasks in the build and deployment process eliminates variation and gives us reliably consistent results.

However, removing people from a process—or expecting people to perform a process by rote—means that the process no longer has the capacity to change, to adapt, or to discover. For example, drug companies have spent billions automating the routine side of drug research. They have replaced lab technicians with robots, making it possible to test far more drug compounds than they could possibly have done before. This was supposed to lead to a lot more blockbuster drugs—but results have been disappointing. The reason, many speculate, is that by “deskilling” the job of drug experimentation and removing the human element, companies made implicit assumptions about what spaces should be explored and lost the human capacity to notice unexpected results and try out new experimental spaces.⁹

The difference between testing automation in drug industries and testing automation in software development is this: The drug testing automation “deskilled” testers (replaced them with robots), while effective automation of software testing “upskills” testers. That is, it automates the routine, repetitive testing in order to free testers up to focus on mistake-proofing the development process, making sure users find the software easy to use, doing exploratory testing, and property testing. In a nutshell, deskilling workers creates interchangeable people while upskilling workers creates thinking people.

The question to resolve before you embark on a lean initiative is this: What do you really believe about people? Consider your attitude toward process. Do you think that a well-documented process that everyone follows without question is the path to excellence? Or do you think that the reason to standardize a process is so that people doing the work have something solid to question and change? Lean principles are solidly based on the second viewpoint.

Consider your attitude toward schedules. Does it make you nervous when someone suggests that the development team should decide what can be done within a timeframe and tell managers, rather than the other way around? Or your attitude toward work assignments. Does it seem unnatural for people to figure out for themselves what to do next rather than being told?

In order for lean to work, your conceptual framework about people has to contain the fundamental belief that the people doing the work know how to do it best. You have to be nervous about automation that would eliminate people from the process or reduce the skill levels needed to do a job. You have to think it strange that many levels of authorization—or even one level of authorization—are required for decisions made on the front line. You have to really believe there is no better way to tackle problems than to give the people doing the work the training, the tools, the charter, and the support to solve their own problems and improve their own processes.

Just introducing a new technology will not necessarily remove the limitation it was designed to remove, because the accommodations made to deal with the limitation are so woven into the fabric of the company that they are not even recognized. For example, when e-mail became widely available from Internet service providers, large companies took years to open their e-mail systems to the outside world. We were sending e-mail to our college-age children from home long before we could communicate with vendors through our work e-mail systems.

The problem in removing limitations is that we not only have to overcome the constraint, we also have to recognize the accommodation that we were making to live with the constraint—always a difficult task—then we have to remove the accommodation and finally, replace it with new rules.

To successfully adopt a new technology, Goldratt says that we must answer four questions:¹²

1. What is the power of the new technology?

2. What limitation does the new technology diminish?

3. What rules helped us to accommodate the limitation?

4. What rules should we use once the limitation is replaced?

Consider Enterprise Resource Planning (ERP), once a new technology that gives managers access to a vast amount of information to help make better decisions. Before ERP, decisions were made based on rules that created local optimization, because there was no data to make system-wide decisions. For example, manufacturing mangers tried to optimize efficiency of machines, and sales managers used product costing formulas to decide how to price products. Making decisions based on local optimization was an appropriate approach when it was the only alternative. These decision rules created much better results than random decisions. However, once ERP provides the data to make better system-wide decisions, local optimization rules must be abandoned or else the potential of ERP will go unrealized. Many of the failures of ERP can be attributed to a failure to remove the accommodations and revise the rules from pre-ERP days.¹³

Goldratt recommends that estimates be acknowledged as just that—estimates—and the safety margin attached to individual estimates should be removed from the activities and accumulated in a project buffer. With this approach, individual activities will be completed much faster, and the project buffer can be spread across all activities to absorb variation. In the book Agile Estimating and Planning,¹⁵ Mike Cohn explains in detail how to do this for software.

Note that project buffers will not speed up overall project execution until accommodations to past practices that are embodied in the expectation and reward mechanisms are changed. In order for Critical Chain to work, everyone—from senior management to those doing the estimates—must abandon the expectation that activities should be delivered within the estimated timeframe. In fact, if half of the activities don’t take longer than their estimated time, the system will not achieve the desired improvement.

An additional problem with using Critical Chain for software development lies in the assumption that all of the activities needed to complete development should be known in advance and that dependencies among them are understood. As we have seen, these assumptions are inappropriate for most software development. First of all we need to abandon the idea that all requirements should be known at the beginning of a development effort. Secondly, we should focus our creative efforts on breaking dependencies.

At a high level, the Critical Chain project buffer may make sense, but at a detailed level, it is an accommodation to the past. If we break dependencies and have a dedicated team develop in small, deployable increments, we no longer have the problems that Critical Chain was designed to solve. A master in the Theory of Constraints would recognize this as a natural result of the application of the Theory of Constraints, scrutinize the accommodation embedded in the Critical Chain approach, and develop the new rules to use now that the constraint has been removed.

The development environment of 30 years ago, 20 years ago, even 10 years ago is entirely different than it is today, and the accommodations we made to deal with limited memory, processor power, communication capability, and software options are no longer appropriate. Object-oriented development, automated unit and acceptance testing, service-oriented architectures, topic-oriented documentation, and innumerable tools for small-batch development have recently appeared and are being constantly improved. The Web has spawned innovations ranging from Open Source development to powerful search capability to Voice-over-IP. In an environment that is changing so rapidly, we would do well to be alert for the accommodations that we continue to make for constraints that are no longer present.

The most effective way to get started with lean development is:

• Train team leaders and supervisors (in preference to change agents).

• Emphasize on-the-job thinking (rather than documentation).

• Measure a few key indicators (as opposed to many data points).

By 1917, Massachusetts had developed a model for American vocational education that was subsequently copied throughout the country, and Charles Allen was its director. There was a war going on, and the US Shipping Board decided to build a thousand new ships. Faced with an urgent need for a tenfold increase in the number of skilled ship builders, the Shipping Board tapped Charles Allen to oversee their training. During the next two years, 88,000 workers went through the training programs Allen developed, which were regarded as a great success. He summarized his experience and philosophy in the book The Instructor, the Man and the Job.¹⁶

Charles Allen felt that most training happened on the job, so he focused on teaching supervisors how to train workers. His first assumption was that supervisors were highly skilled at the work they supervised. Allen’s training programs taught supervisors how to transfer this knowledge to new workers using four steps: preparation, presentation, application, and testing. At the same time that the automobile industry was teaching industrial engineers to find the “one best way” and tell workers what to do, Allen was teaching shipbuilding supervisors to cooperate with workers to solve problems. His philosophy was, “If the learner hasn’t learned, the teacher hasn’t taught.”

Fast forward 20 years to 1940. The US War Production Board faced a similar problem: A rapid escalation in the production of aircraft and munitions created a huge demand for skilled workers, which was exacerbated by the departure of most of the available young men to fight the war. Drawing upon Allen’s success, the War Production Board developed Training Within Industry (TWI), a program focused on training supervisors how to train workers. The basic modules of this training program were:¹⁷

• Job Instruction (JI): This training program was based on the assumption that experienced workers might be very good at what they do, but they may have little experience teaching others how to do the same thing. Using Allen’s four steps, supervisors are taught to 1) prepare the worker, 2) present the operation, 3) have the worker try the operation, 4) follow-up by checking frequently, encouraging questions, and gradually tapering off coaching as the worker becomes proficient.

• Job Methods (JM): This training program was based on the assumption that workers have many good ideas about how to improve things, but they may not be encouraged to act on these ideas. Supervisors were taught to help workers: 1) break down the job, 2) question every detail, 3) develop a new method along with colleagues, 4) sell the new method broadly, get approval and apply it.

• Job Relations (JR): This training program taught supervisors to treat people as individuals and helped them resolve “people” problems effectively and fairly. Supervisors were taught to: 1) get the whole story; 2) weigh the issues, don’t jump to conclusions; 3) take action, don’t pass the buck; 4) follow-up and check results.

Following Allen’s lead, TWI training assumes that first line supervisors know how to do the job of the people reporting to them, and therefore can act as a teachers. It is interesting to note that Deming’s sixth and seventh points address the same issues as the TWI training program:

6. Institute training. Managers should know how to do the job they supervise and be able to train workers.

7. Institute leadership. The job of managers is to help people do a better job and remove barriers in the system that keep them from doing their job with pride.

Perhaps 2 million US supervisors received TWI training, which was credited with large increases in productivity and a huge drop in scrap and grievances. As the war came to an end in 1945, so did the TWI program—at least in the US. TWI training was offered in countries recovering from the war and was especially well received in Japan. As it did with Deming’s ideas, Toyota brought the TWI ideas inside, added its own experiences and made it a uniquely Toyota program. To this day, supervisors at Toyota receive training based on the ideas of Charles Allen as implemented in the TWI program.¹⁸

Most improvement programs put far too much emphasis on documentation and not nearly enough emphasis on encouraging every person to think every minute about how her or his work situation might be improved. Of course, most companies believe that they encourage workers to think about improvements. For years we have had suggestion systems that encourage workers to write down their good ideas and submit them to the suggestion system, and for years suggestion programs have turned in a dismal track record of improvements. In software development, we use retrospectives to generate lists of things that should change, but too often the same list seems to get generated time and again.

The problem is, most of the ideas from our suggestion programs and brainstorming sessions are turned over to someone else for evaluation and occasionally for implementation. This is a mistake. The people with ideas, working with their teams, should be the implementers of their ideas. They should not be asked to drop their ideas into a suggestion system to be implemented by others. They should not just add their ideas to a long list of good ideas. When good improvement ideas become someone else’s problem, the originators have less personal investment in pursuing the idea, and tacit knowledge about the problem is left behind as well.

All workers, all the time, should be expected to question how their current process works and actively encouraged to use effective problem-solving techniques to try out new ideas and implement those that work. Documentation should exist as a basis for this problem-solving process. It should be developed by work teams, used by work teams, maintained by work teams, and readily changed by work teams.

If we value engaged, thinking people, we have to take a hard look at assessment programs that are based on documentation. Typically these programs measure the maturity of an organization by its conformance to documented procedures. While the objective seems innocuous enough on the surface, in practice the assessment process usually places pressure on an organization to freeze its documentation and therefore not change its processes. The result is a disturbing tendency to remove the “right to think” from front-line workers. Quite often workers are encouraged to do exactly what is documented, while the proper emphasis would be to encourage workers to constantly question what is documented. Documentation-focused assessment programs tend to value the stability of the documentation. In fact, they should view frequently changing documentation as a sign of an organization that has learned how to think.

Trying to improve the wrong measures creates the wrong incentives—often leading to unintended consequences. For example, project managers are often measured based on earned value. However, earned value is a measurement of adherence to plan; it ignores the question of whether or not the plan is the best way to achieve the desired results. This is how we get software delivered on time, on budget, with planned scope complete, but still have dissatisfied customers.

So what measurements should we use to encourage the right behavior? We propose that instead of proliferating measurements, it is best to reduce the number of measurements and find system-level measurements that drive the right behavior at the subsystem level. In lean organizations, it is well known what these measurements are: cycle time, financial results, and customer satisfaction. Let’s consider how they might be used in software development.

When you measure cycle time, you should not measure the shortest time through the system. It is a bad idea to measure how good you are at expediting, because in a lean environment, expediting should be neither necessary nor acceptable. The question is not how fast can you deliver, but how fast do you repeatedly and reliably deliver a new capability or respond to a customer request.

The objective of a development organization is to first of all establish a repeatable, reliable cycle time for each classification of work, and then to reduce that cycle time through continuous improvement. This single measurement drives all manner of good behavior in every area of the organization, because it aligns everyone in making the right tradeoffs.

Focusing on cycle time reduction requires the full engagement of the people adding value. It drives collaboration, it drives world-class quality, and it drives standards. Almost everything else you might measure—ability to meet deadlines, quantity of work produced, speed to market, even utilization—will improve with cycle time reduction. However, the opposite is not the case; if you focus on optimizing the subsystem measurements, cycle time will probably move in the wrong direction.

If the ultimate goal of the development effort is to create a profitable product, then the development team should understand the profit and loss (P&L) model for the product so they can gear their work to create the most profitable product. For internal development, contracted development, or nonprofit development, the team should be challenged to realize an appropriate return on investment (ROI) or whatever other business metric (e.g., throughput) is used to justify the investment.²⁰

We have found that most companies do not expose their development teams to the financial implications of their work. However, every development team we talk to would be delighted to understand the financial objectives of their efforts, make tradeoff decisions with those objectives in mind, and experience the sense of accomplishment that comes from having met those objectives.

Sometimes the objective will not be financial: it may be increased audience for a public radio station, number of children receiving vaccinations, etc. In any case, the first step in chartering a development team is to communicate a clear and compelling statement of what constitutes success, and the final step is to measure that success—or lack thereof—and make it visible.

Reichheld proposes a single, simple measurement to find out if customers are delighted: the net promoter score. Ask customers one simple question: How likely are you to recommend our product or service? Customers respond on a scale of 0 (would not recommend) to 10 (will definitely recommend). The responses are grouped thus: Scores of 9 and 10 indicate a “promoter.” Scores of 0–6 indicate a “detractor.” Scores of 7 or 8 indicate a passive customer. These scores are similar to grading in school, where 90–100 is an A or B while scores below 70 are failing scores.

To calculate a net promoter score, subtract the percentage of detractors from the percentage of promoters. You will get a number between -100 percent and 100 percent. Average companies might have a score around 10 percent. Really good companies are in the 50 percent or higher range. Negative scores are cause for serious concern. Reichheld presents evidence that the net promoter score is highly correlated to both market share and profitability, making it a good high-level view of customer satisfaction in a single number.

Lean development is a journey that begins where you are and takes you far into the future. As a farewell, we offer a brief roadmap for getting started on your journey:

1. Begin where you are: How do you create value and make a profit?

2. Find your biggest constraint: What is the biggest problem limiting your ability to create value and make a profit?

3. Envision your biggest threat: What is the biggest threat to your ability to continue creating value and making a profit over the long-term?

4. Evaluate your culture: Establish and reinforce a culture of deep respect for front-line workers and for partners. Remove barriers that get in the way of pride in workmanship.

5. Train: Train team leads, supervisors, and managers how to lead, how to teach, and how to help workers use a disciplined approach to improving work processes.

6. Solve the biggest problem: Turn the biggest constraint over to work teams. Expect many quick experiments that will eventually uncover a path to a solution.

7. Remove accommodations: Uncover the rules that made it possible to live with the constraint. Decide what the new rules should be.

8. Measure: See if end-to-end cycle time, true profitability, and real customer satisfaction have improved.

9. Implement: Adopt changes supported by results.

10. Repeat the cycle: With the biggest problem addressed, something else will become your biggest problem. Find it and repeat the cycle.

2. Restructure the measurements: Chances are very high that there are local measurements within the value stream, and chances equally high that these measurements lead to suboptimization—or worse—dysfunction. Stop using the local measurements, and use value stream measurements instead.

3. Reduce the cost of crossing boundaries: If there are big delays in a value stream, they probably occur at department or company boundaries. Look at these boundaries carefully and evaluate how much they are actually costing. Anything you can do to speed the flow of value across these boundaries will almost certainly reduce the cost of crossing the boundary.

5. Move responsibility and decision making to the lowest possible level: Your lean initiative should be implemented by the work teams that create value under the guidance of their existing leaders. Have work teams design their own lean processes, with guidance from properly trained team leads and supervisors. Expect the work teams to ask for what they need to make the new processes work.

6. Foster pride in workmanship: Many things impede pride in workmanship: individual over team rewards, sloppy workspaces and work practices, impossible deadlines, no time for proper testing or refactoring, imposed processes, routine or robot-like jobs, etc. Root out and eliminate these practices: never create conflicting incentives among team members, automate routine tasks, let workers decide the best approach to their job, never ask for sloppy work in the interest of meeting deadlines. Encourage passionate commitment and expect top-quality results. This will have a more sustained positive impact by far than individual incentives and bonuses.

8. Limit work to capacity: Have teams work at a repeatable cadence to establish capacity. Expect teams to pull from queues based on their proven velocity and to completely finish the work before they start on more work. Limit queue sizes, and accept no work unless there is an empty slot in a queue.

9. Focus on cycle time, not utilization: Stop worrying about resource utilization and start measuring time-to-market and/or customer response time.

11. Break dependencies: Instead of worrying about dependencies, do everything possible to break them so that any feature can be added in any order. A divisible systems architecture is fundamental. Ruthlessly question dependencies, and tolerate them only very sparingly.

12. Maintain options: Develop multiple options for all irreversible decisions and never close off an option until the last responsible moment. Critical design decisions are tradeoffs. Invest enough in understanding the impact of each option to have the data and the confidence to make the best choice. For all other decisions, create change-tolerant code, keep it clean and simple, and do not hesitate to change it.

14. Maintain a culture of constant improvement: Create the time and the expectation that every team and every function will continually examine and improve its processes and test its assumptions. Hold cross-team and cross-functional events to identify accommodations and constraints in the flow of value and replace these with practices and policies that will improve overall results.

15. Teach problem-solving methods: Teach the PDCA cycle or the scientific method or some variation of these problem-solving methods. Expect teams to establish hypotheses, conduct many rapid experiments, create concise documentation, and implement warranted changes.

17. Automate: Accept that people make mistakes, and mistake-proof through automation. Automate every process you can as soon as early as possible. Automate testing, builds, installations, anything that is routine, but be sure to automate in a way that supports people and keeps them thinking about how to do things better.

18. Refactor: Keep the code base clean and simple, and the minute duplication shows up, refactor the code, the tests, and the documentation to minimize complexity.

20. Create nothing but value: Assure that all steps in all processes are focused on value-creating activities or improved capability to deliver value in so far as this is possible. Measure process cycle efficiency and keep on improving it.

21. Write less code: Aggressively limit the features in a system to only those that are absolutely necessary to add value. Develop an organizational intolerance for complexity.

2. Information for this section came from Automobiles: Toyota Motor Corporation: Gaining and Sustaining Long-term Advantage Through Information Technology, case prepared for the Columbia Project: Use of Software to Achieve Competitive Advantage, by William V. Rapp Co-Principal Investigator The College of International Relations Ritsumeikan University Kyoto, Japan, April 2000.

3. See The Toyota Way Fieldbook by Jeffrey Liker and David Meier, McGraw Hill, 2006, pp. 208–212.

4. Arie de Geus, The Living Company: Habits for Survival in a Turbulent Business Environment, Harvard Business School Press, 1997, 2002, p. 1.

5. See Clayton Christensen, The Innovator’s Dilemma, Harvard Business School Press, 1997; Harper Business, 2000, and Clayton Christensen and Michael Raynor, The Innovator’s Solution, Harvard Business School Press, 2003.

6. Eiji Toyoda, Toyota: Fifty Years in Motion, Kodansha, 1987. First published in Japanese in 1985.

7. See Automobiles: Toyota Motor Corporation: Gaining and Sustaining Long-Term Advantage Through Information Technology, case prepared for the Columbia Project: Use of Software to Achieve Competitive Advantage, by William V. Rapp Co-Principal Investigator The College of International Relations Ritsumeikan University Kyoto, Japan, April 2000.

8. Ibid., and see also Larry W. Hunter and John J. Lafkas, “Opening the Box: Information Technology, Work Practices, and Wages,” Working Paper 98-02-C, Wharton, Financial Institutions Center, June 1999.

9. From “Supporting Cheap and Rapid Iteration (with a Human Touch)” by Robert D. Austin, Cutter Consortium Business-IT Strategies Advisory Service, April 19, 2006.

10. TPS vs. Lean and the Law of Unintended Consequences, by Art Smalley, www.superfactory.com/articles/smalley_tps_vs_lean.htm.

11. Beyond the Goal, by Eliyahu Goldratt, Your Coach in a Box Series, Gildan Autio, 2005.

12. Ibid.

13. Ibid.

14. Ibid.

15. Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2006, Chapter 17.

16. Charles Allen, The Instructor, the Man and the Job: A Handbook for Instructors of Industrial and Vocational Subjects, J. B. Lippincott Co., Philadelphia, 1919.

17. See Jim Huntzinger, “The Roots of Lean,” www.lean.org/Community/Resources/ThinkersCorner.cfm.

18. See TPS vs. Lean and the Law of Unintended Consequences, by Art Smalley, Ibid.

19. October 8, 2003, Public Affairs Report, Toyota Motor Corporation, www.toyota.co.jp/en/special/tps/tps.html.

20. For examples of P&L and ROI models for development teams, see our first book, Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck, Addison-Wesley, pp. 83–91.

21. See The Ultimate Question: Driving Good Profits and True Growth, by Fred Reichheld, Harvard Business School Press, 2006.

22. Lao-tzu (604 BC–531 BC), The Way of Lao-tzu; this has also been translated, “A journey of a thousand miles begins where you stand.”