Thursday, February 21, 2002

Lean Product Development

Agile Approaches have been the target of some serious criticisms: they don’t provide adequately for an overall design, they don’t scale, and they only work with skilled developers. If these criticisms are true, then agile methodologies might go the way of the dot-com’s. In order for agile methods to be sustainable, they must be able to deal with design, they have to scale, and ordinary people have to be able to implement them.

It might be instructive to find companies which have sustainable agile development approaches, and see how they do it. If we look to new product development, instead of software development, we can find companies which have world class product development records going back 50 to 100 years. 3M and Toyota would be a couple of good examples. How have they sustained agile development practices?

“3M’s core competency, in fact, its core business, is the building of businesses.” According to CEO, Jim McNerney. At 3M, every business manager knows that 30% of their products have be less than 4 years old.

“The real difference between Toyota and other vehicle manufacturers is not the Toyota Production System, it is the Toyota Product Development System.”, claims Kosaku Yamada, Chief Engineer of Toyota’s Lexus line. Toyota churns out many superb cars with amazingly short development times.

3M uses small development teams (a dozen people over a year), while Toyota teams are large (500 people, 3 years). Both companies have very agile processes, which they have sustained for decades.

1. Management
Both 3M and Toyota use balanced matrix management approaches. Every new product program has a strong leader, at 3M it is the ‘champion’ and at Toyota it is the shusa or chief engineer. In both cases, these people ‘own’ the product – their name is associated with it. We have Art Fry’s Post-it notes and Kosaku Yamada’s Lexus. These leaders are the ‘voice of the customer’ to the team and they assure the proper amount of design goes into it before detailed development proceeds. They have the best job in the company and ‘developers’ are dying to be allowed to work on their teams.

At both Toyota and 3M, the ‘developers’ stay in their functional departments while on the team. This is because the functional department provides the apprentice, journeyman, master – type training that developers need to master their craft. Functional managers get involved at a detailed level with newbies, less with more senior people. They provide training and guidance, assistance with standards and proper ways to investigate new ideas and publish results.

2. Process
The concept of a project manager is foreign to both companies, as is the idea of monitoring tasks. Both companies work on a ‘gate’ system, where the gate is a prototype tested against customers. Developers, assisted by guidance and support from their functions, are expected to meet gate milestones and meet quality standards set by the leader, but it is not the leader’s responsibility to be sure they do, it is the function’s responsibility.

Although product development practices are quite consistent across each company, neither would measure very high on the CMM scale. Both companies engage in highly disciplined learning activities, but neither considers documenting procedures to be the appropriate value. Instead, each company in its own way uses the Scientific Method to explore hypothesis, publish results and design new products.

3. Learning
3M developers are scientists, inventing and patenting new materials and processes. Of course they keep very careful records and read all related literature. The have to, it’s all part of the patent process. Toyota developers are engineers, establishing tradeoff’s in charts and graphs. If a styling engineer wants to know the effect of a certain curve in a radiator on its cooling capacity, there will be a graph which shows the answer over a range of allowable curves.

The operable word here is publish, not document. 3M’s scientists and Toyota’s engineers are making the results of research available to their peers in the time-honored way of all researchers. They do not create a knowledge database, they write up results and submit them to peers who are keenly interested in their research, give talks, publish papers. The 3M scientists, mostly PhD’s, learned how to do this in graduate school.

Development Approaches
1. Spanning
Cars design involves a series of complex tradeoffs. The process of development involves setting up methods of communication so these tradeoffs can be made as effectively as possible, while focusing all the time on the ultimate vision - producing a car with integrity, that will feel like the best possible choice for its target market. Toyota is particularly good at this, and they do it by starting with a rough design of the whole car and refining it systematically, making tradeoffs at increasingly finer levels of detail.

The equivalent approach in software development is to choose the simplest spanning application possible, and implement it first. This technique is particularly good for testing component ensembles and legacy system upgrades. For example, when replacing a legacy insurance system, one would start with a simple type of policy and implement it from front to back – new policies, renewal, claims handling, and termination. The idea is not to implement module-by-module, but implement a single thread across the entire system, so as to test the interactions of all parts of a system along a narrow path.

2. Synchronization
Toyota has many independent teams working on a product, and even with the small teams at 3M, co-location of a product team is rare. It is deemed more important that a scientist be near the sophisticated equipment and knowledgeable colleagues associated with their specialty. But communication is smooth and effortless, because team members are making something together. The concrete thing they are building – a clay model of a car or a mock-up of a new traffic sign – keeps the team in touch.

All development is a series of design-build-test cycles, and the more frequently these occur, the better. Synchronization through short design-build-test cycles improves cross-functional communication and speeds up development. This concept is directly applicable to software development, where it is widely recognized that daily (or more frequent) builds with automated testing is the best way to build a robust system rapidly.

3. Convergence
Most people are annoyed when someone announces a meeting without checking to see if everyone is free. Such meetings must often be rescheduled (many times!) or missed by key people. We know it is easier to set up meetings by getting everyone to list their free time and look for an overlap.

Toyota and 3M use the same concept for product design. They explore the entire solution space and find intersections that everyone finds acceptable, gradually adding detail and converging on a solution. This approach is called set-based design, and contrasts sharply with point-based designs which start with a single solution that undergoes a series of optimizations. In most cases, set-based design produces the best design in the shortest amount of time with the least amount of communication. It’s strange that this principle, so obvious when you are scheduling meetings, seems counterintuitive in the development environment.

Lessons for Software Development
  • A ‘Champion’ provides the integrating force to be sure that the necessary level of overall design is established and the customer voice is unified, clear and available to the team.
  • Functional managers provide training and guidance for team members and establish a place for them to interact with others in their specialties.
  • Teams are small and operate independently. They are responsible for designing their own processes and tracking their work so as to meet deadlines.
  • Learning both by individuals and across functions is standard operating procedure. Development is a process of observing, predicting, testing and publishing results.
  • The entire problem is divided into segments to be addressed concurrently by small teams. The design process converges on a solution, rather than selecting one at the onset.
  • Coordination across teams and functions is established through daily builds and frequent iterations.
  • Development starts with the simplest possible spanning application. This helps to establish feasibility and architecture; it also lays the groundwork for multiple teams to work concurrently.
Screen Beans Art, © A Bit Better Corporation