Cusumano: At a higher level of If you look at waterfall vs. agile/lean principles, there are a half-dozen points methods, or what Selby and I called the that I make. The most critical one is ‘synchronize-and-stabilize’ approach, about waterfall’s sequential approach which is the name we used in the to development vs. doing things book about Microsoft, the company concurrently or in parallel. In both was doing a lot of things in parallel. cases, when you do things sequentially They would start writing code before it’s going to take a longer time. they had a complete specification. Sometimes they never got a complete So why was GM’s product development spec. They would start integration cycle 64 months back then? It was testing as early as possible; they didn’t because of the way they scheduled wait to test a system until the end. things. They had certain bottlenecks and couldn’t do certain things in parallel Another thing we found was that there because they had never tried to do could be a lot of wasted effort if you them in parallel. When we looked at have to redo a lot of work. If you built how the Japanese auto companies got a prototype of a software product and product development down to 40-42 showed it to customers early, you could months, they were doing a whole eliminate a lot of those changes later bunch of things in parallel. For example, on. Even if you were doing a lot of what they were starting their manufacturing seemed to be re-work, or fixing bugs, preparations and die manufacturing early by throwing code into integration almost concurrently. They were sharing tests early, you were still saving yourself information with the different teams. a lot of time in the end. As soon as they could figure out the dimensions of a car door, the die guys Firms that did early prototype-driven would start working. They didn’t wait development—and not just throw-away until the whole car was designed. So they prototypes—but working prototypes, started overlapping a lot of those phases. and then did small incremental but frequent builds, and continuous design