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.

Organization
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

The Leadership Paradox

“No one has yet figured out how to manage people effectively into battle; they must be led,” wrote John Kotter in ‘What Leaders Really Do’[1]. He notes that leadership is about helping people cope with change, while management is about coping with complexity. Leaders set direction, managers plan and budget. Leaders align people, managers organize and staff. Leaders motivate, managers control.

Champion
In this context, it should not be a surprise that each new product development program at 3M is led by a ‘champion’. Innovation at 3M is brought about by excited, motivated teams. They are led by a product champion who probably wrote the initial product concept, gathered management support for the program, and recruited most of the team. The champion interprets the product vision for the team, thus representing the customer who is not, after all, on site. The champion sets the pace of development and determines how decisions get made. A champion is also expected to keep working on a good idea even if the program gets killed by management.

Shusa
Similarly at Toyota, a new vehicle development program is led by a shusa or chief engineer. In contrast to the coordinating role of a new vehicle manager at US auto companies, the shusa has complete responsibility for the vehicle, and has the authority necessary to make all program decisions. The shusa has been called a ‘heavyweight program manager’[2], but this is a misnomer, because a shusa is a leader, much more than a manager.

Perhaps the correct characterization of a champion or shusa is a ‘respected leader’. The emphasis of the role is on setting direction, aligning the organization and motivating the team. At 3M, the champion is largely self-nominating, and in both companies, the role holds great stature. In both 3M and Toyota, the product produced by one of these leaders often bears their name (Fuji-san’s car or Art Fry’s Post-it® notes). These companies seem to understand that if a team is to deal with change and innovation, a ‘respected leader’ is needed; a coach is not enough and a manager (in the traditional sense) is the wrong approach.

Software Development
It has been claimed[3] that software development is similar to new product development, because it is an activity which creates something unique for a customer, something which has not been made before. In this sense, programming is not like manufacturing, which makes the same thing many times over and strives to make each instance the same.

If software development is like new product development, then how should software projects be led? There seems to be some ambivalence surrounding the role of leadership in agile methodologies, possibly stemming from the traditional role of a project manager in software development projects. Often the project manager does not have a technical background and may not feel responsible for understanding the technical aspects of the project. Usually the project manager is trained for and measured against the controls of scope, budget and schedule. This administrative role is quite different than the leadership role exercised by a champion or shusa .

If a software project requires vision and must cope with change, this is not going to come from following the rules taught in project management certification courses. If stakeholders need to be aligned and the team needs motivation, managing scope, schedule and cost is not the place to focus attention.

Scrum Master
What are the alternatives to project managers? Beck suggests the use of a ‘coach’. Schwaber and Beedle propose role of a ‘Scurm Master’: ‘The Scrum Master represents management and the team to each other.’[4] ‘… is in touch with all aspects of the project…’[5] ‘… is responsible for ensuring that impediments are promptly removed and decisions are promptly made.’[6]

A coach or Scrum Master is not quite the champion of 3M or the shusa of Toyota, but then again, there is a difference between new product development and most software development. At 3M and Toyota, the customer is not readily available and must be represented. In fact, it’s pretty well accepted at 3M that asking existing customers what they want is not the way to come up with innovations. Instead, you have to understand the problems that customers have, anticipate future needs, and invent something new to solve their problems. A 3M champion creates and communicates a vision of the new product, just as at Toyota, the shusa writes the description of the new vehicle. To do this, they need a high degree of technical expertise as well as a deep understanding of the customers.

Most agile methods depend upon the ‘customer’ to create a vision of the software under development. Sometimes this will work, but it places a large and sometimes unrealistic burden on the customer. While the champion and shusa are technical experts, the customer usually is not, so the customer’s vision of a solution may be limited. In practice, customers often don’t know what they want, and to make matters worse, there are often multiple stakeholders, making it unclear who the ‘customer’ really is.

The Scrum Master represents the customer to the team, and thus must understand who the customer is and what all the stakeholders really want. However, the Scrum Master is not chartered to come up with the technical vision of how to address the customers’ needs. In XP, the technical vision of the system is expected to evolve throughout multiple iterations.

Design vs. Vision
The biggest criticism of agile methodologies is that they do not provide for overall design prior to the beginning of development. At Toyota and 3M, the product largely emerges from the development process, but the programs start with an overall technical vision of what the product will look like in the end. In fact, the shusa has been equated to a system architect of a new car.[7] Both the shusa and the champion are leaders, not managers, but as very experienced technical leaders, they provide the overall design to the product under development, or assure that an overall design is established by the team. They judge the level of design necessary to allow development to proceed in an emergent manner, while assuring that there are no downstream surprises which should have been anticipated.

If a development process must deal with ‘wicked problems’ (see separate essay), then by definition, the solution emerges as development proceeds. Such projects need someone to make the tradeoffs between early design and emergent development. In world class new product development organizations, this role belongs to the champion or shusa, a ‘respected leader’ with the technical and customer savvy to make such tradeoffs.

Technical Lead
Experience shows that if there is not someone to make similar tradeoffs for a software system, large organizations have a tendency to err on the side of caution. A corporate architecture committee, customer committee or administrative coordinators will usually lack an overall vision of the project, and so will look for comfort in detail, even though the detail is not what is needed to proceed safely. It would be better if there were a technical lead on the program to create and be responsible for maintaining the technical vision. It would not be so good, however, if the technical lead were not a leader. A leader not only sets direction, but also aligns and motivates people. The shusa and champion are expected to secure resources, remove impediments, and lead the team into battle. A technical lead who either sits on a pedestal or on the sidelines will not be able to lead the team.

If becoming a technical guru or a PMI graduate does not make a person into a leader, then how should leaders be developed? First, an organization should understand what it means to develop leaders. The armed forces develops leaders as their primary responsibility. A Special Forces team, composed of a dozen experts and a leader, is expected to adapt continually to very demanding conditions, given only the broadest of objectives. But even the most ordinary army units are composed of teams with a leader who is expected to respond to events on the ground, adapt to changing conditions, make decisions and lead the team. Although military training is not being advocated, it might be educational to understand how the military trains its leaders.

Developing Leaders
At 3M, people with technical competence are encouraged to develop a new product concept based on solving a customer problem. In order to carry out that vision, they find they need to recruit and motivate a team and secure resources from the organization. This is one of the most popular career paths in the technical organization, and so many technical people learn how to follow this path.

Toyota and 3M have learned how to make the role of technical leader one of the most desirable in the corporation, and thus they are able to develop a large number of qualified leaders. On the contrary, project management is frequently considered an undesirable career path for software developers, so few seem interested in learning how to manage. To break this vicious circle, an organization needs to begin by considering how to make the role of project leadership attractive to technical experts. Changing job expectations from administration and management to vision and leadership would be a good start.

Finding Leaders
Where does an organization find people to fill the newly defined role of project leader? In many cases the training ground might already be in house. In the past ten years, supervisors and managers in operational areas such as manufacturing, logistics and customer service have been trained to focus on empowering the first line workers to deal with problems and improve their own processes. Thus many organizations already have leadership development programs in place, they just haven’t moved beyond the operational areas yet.

Good operations managers are likely to make good software project leaders, because they have already learned how to work with people and lead a team. If you are blessed with good operations, then look for respected supervisors and first line managers in operations who have a technical background or aptitude, and consider training them as project managers. Alternatively, but not as good, consider sending everyone who will lead a software team to a good training program for first line supervisors in an operational area. But note that it is easier to develop people who know how to lead into managers than it is to develop people who know how to manage into leaders.

You Get What You Expect And What You Inspect
The bottom line is that people respond to the expectations of their management. Software project leaders do not develop in a position where the primary expectation is change control and the primary measurement is earned value. An organization will get what it values, and the agile methodologies do us a great service in shifting our perception of value from process to people, from documentation to code, from contracts to collaboration, from plans to action.
______________________
Footnotes:

[1] ‘What Leaders Really Do’, John P Kotter, Harvard Business Review, Volume 79, Number 11. Reprint of article first printed in 1990.

[2] ‘Toyota’s Principles of Set-based Concurrent Engineering’, Durward K. Sobek II, Allen C. Ward and Jeffrey K. Liker, Sloan Management Review, Volume 40 #2, Winter 1999, and Product Development Performance: Strategy, Organization, and Management in the World Auto Industry, Clark, K.B. and T. Fujimoto, Harvard Business School Press, 1991.

[3] See, for example, Agile Software Development with Scrum, Schwaber, Ken and Mike Beedle, Prentice Hall, 2001, Chapter 6.

[4] Agile Software Development with Scrum, Schwaber, Ken and Mike Beedle, Prentice Hall, 2001, p 31

[5] Agile Software Development with Scrum, Schwaber, Ken and Mike Beedle, Prentice Hall, 2001, p 142

[6] Agile Software Development with Scrum, Schwaber, Ken and Mike Beedle, Prentice Hall, 2001, p 32

[7] ‘Toyota’s Principles of Set-based Concurrent Engineering’, Durward K. Sobek II, Allen C. Ward and Jeffrey K. Liker, Sloan Management Review, Volume 40 #2, Winter 1999

Screen Beans Art, © A Bit Better Corporation

Reflections on Development

Software Development is just that ‘Development’. Writing software involves creating something new. (After all, if developing software were repeatable, a computer could be programmed to do it.)

If we cast around for other uses of the word ‘Development’, we find that it means:

1. Fund raising for a non-profit corporation


2. Turning vacant land into a subdivision or shopping center


3. Commercializing new products

Bypassing definitions (1) and (2) for the moment, let’s consider the third. If we determine good New Product Development practices, might we come up with some good ideas for Software Development? It seems that Software Development might learn a lesson or two from New Product Development.

New Product Development has been around for a long time. Some companies do a great job of it, and we can look at corporate track records and find out which ones do it well. In fact, some companies do New Product Development so well that they are considered benchmarks of excellent Product Development practices. Two companies which clearly qualify for this honor are Toyota and 3M.

Toyota has the fastest product development times in the automotive industry, is a consistent leader in quality, has a large variety or products designed by a lean engineering staff, and has maintained US market share despite a strong yen.

Almost half of all 3M products are only 5 years old, and its innovation machine continues to roll out an astounding number high quality of new products every year. New product development practices at 3M have been studied and imitated for over a decade.

Development methods used by 3M and Toyota may be distilled into to four key practices:

1. Use Entrepreneurial Teams


2. Focus on Business Value


3. Overlap Development Phases


4. Converge on Solutions

Use Entrepreneurial Teams
3M has a 15% rule: All scientists may use 15% of their time working on any project they wish. In addition, the company expects all new product teams to be led by a ‘Product Champion’. The champion typically has an entrepreneurial vision of a new product, and recruits scientists to use their 15% time to help develop the vision. New product teams can make great progress on company time with no official approval, and once they have developed their idea far enough, they appeal to the company for funding to bring their venture to market.

A new product development team at 3M is cross-functional, collaborative, autonomous and self-organizing. It deals well with ambiguity, accepts change, takes initiative and assumes risks. If the team is making progress toward a new product, it will be left alone.

Teams at Toyota are led by a chief engineer who is expected to understand the market and whose primary job is vehicle system design. The Chief Engineer is totally responsible for vehicle development, similar to the product champion at 3M. This creates an entrepreneurial environment in which the second practice can be accomplished:

Focus on Business Value
3M new product development teams have a wide measure of freedom and extremely challenging goals. But these goals are not cost, schedule and scope. At each review, the key hurdle the team must pass is proving that the proposed product has a good margin potential. One reason why 3M gets hundreds of high margin new products each year is because senior management decision-making focuses teams on this broad strategic goal.

Toyota was the birthplace of Lean Production, originally known as the Toyota Production System (TPS). The fundamental concept of the is to eliminate waste, which means eliminating anything which does not add business value. Toyota was the first company to eliminate sub-optimized measurements and allow overall business value to drive decisions at every level. This tends to knock down barriers between departments and facilitates the third practice:

Overlap Development Phases
At 3M, product development appears to move through a set of phases: concept, feasibility, product and process development, pilot production, scale-up. In fact, with a single cross-functional team handling the product from start to finish, a new product will be manufactured on a pilot line and test marketed as early as possible. Changes will be made to the product spec, to the manufacturing process and to the product design, based on feedback from the manufacturing line and from customers. The major problem with this approach is that when a pilot product is successful, the team may not be able to scale up fast enough to meet demand. It’s a nice problem to have.

Toyota uses compressed overlapping phases to rapidly bring new products to market. Traditional serial engineering in the automotive industry involves moving a design from styling to marketing to body to chassis to manufacturing. At Toyota, concurrent engineering takes place: styling, body, chassis and manufacturing designs are done simultaneously, even as market investigation continues. This works because each function develops multiple options, and the Chief Engineer integrates the product by looking for intersections between feasible regions of functional designs. Which leads to the fourth practice:

Converge on Solutions
Toyota makes more clay models than other companies, freezes the nominal dimensions far later than US manufacturers, and obtains detailed input on process capability at the earliest stages of design. Instead of optimizing from a single starting point, tradeoffs are made by rigorously evaluating sets of alternatives, bringing forward multiple options, making tradeoffs based on data, and deciding as late as possible in the design process.

Similarly, 3M teams would not be expected to know at the beginning of a new product development project exactly what they will commercialize. After all, Art Fry was trying to make a sticky bookmark when he invented Post-it® Notes. When there are inventions to be made and markets to be tested, the product development team tries out many ideas, abandoning the ones that fail and pursuing those that work. Failure is not a problem at 3M – less than half of new product development projects are expected to succeed. But from an abundance of options comes an large number of innovative products, including a regular stream of blockbuster successes.

Conclusion
Software Development, in as much as it is really ‘Development’, might well borrow a few ideas from companies that have mature, high performance development practices. Truly innovative development comes from entrepreneurial teams expected to deliver business value, where all functions work in parallel to converge on an optimal solution.

Screen Beans Art, © A Bit Better Corporation