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

Zero Defects Mentality

A ‘zero defects mentality’ is a bad thing in the military. “Demanding such a rigid standard produces timid leaders afraid to make tough decisions in crisis, unwilling to take the risks necessary for success in military operations,” Perry said. “This zero defects mindset creates conditions that will lead inevitably to failure ….”[1]

A Military Tradition
William G. Pagonis, director of Logistics during the Gulf War of 1991, wrote about the time he led his small company into crossfire to rescue stranded soldiers, against the orders of his commander: “…following a time-honored tradition in the military, I developed ‘radio trouble’ – that is, I turned the communications gear off…” and led a volunteer team to the rescue.[2]

William McKnight, who created the 3M culture of innovation, once said “Those to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way. Mistakes will be made. But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell people exactly how they must do their jobs.” [3]

Good organizations understand that in a dynamic environment, the safest course is to develop intelligent, courageous people who understand that they are expected to exercise their own initiative. Most organizations would like to think that they empower people, but their behavior would suggest otherwise.

What Would You Do?
Ponder this: What is your organization’s instinctive reaction when things go wrong?

1. Reorganize.
2. Develop a better plan.
3. Send in a swat team to improve the processes.
4. Work with the front line people to find out what they think is wrong and how it can be fixed.

Collin Powell has said: “Organization doesn’t really accomplish anything. Plans don’t accomplish anything, either. Theories of management don’t much matter. Endeavors succeed or fail because of the people involved.”[4] So you can imagine what his choice would be.

The Paradox: Superior Performance Comes From Low Control
Organizations which tolerate mistakes and overlook disobedience build an organizational culture in which everyone knows that the best way to tackle the really tough problems is through the people who are closest to them. They also build a cadre of front line workers who are not afraid to think and act on their own. Such organizations are the envy of their industries, even as their competitors try to reorganize, plan and improve processes in an attempt to compete.
__________________
Footnotes:

[1] Defense Secretary William J. Perry, Quoted by Linda D. Kozaryn, American Forces Press Service, August 6, 1996.

[2] ‘Leadership in a Combat Zone’ by William G. Pagonis, Harvard Business Review, Volume 79 number 11, December 2001.

[3] William McKnight, President and CEO of 3M from 1929–1966, quoted in Brand of the Tartan by Virginia Huck, Minnesota Mining and Manufacturing, 1955.

[4] ‘Great Military Leaders’ http://www.geocities.com/Pentagon/Bunker/6513/

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