Rod Coffin’s Weblog

I recently returned from Europe where Dave Nicolette and I facilitated a TDD workshop at the XP Days Benelux and XP Days Germany conferences. I always find that I return from gatherings such as these with a ton of exciting ideas and this time was no exception. One area that I’m particularly interested in exploring is the relation between software development and the product development of manufactured goods. I’ve studied a fair amount about lean manufacturing but haven’t explored much about the product development side of things. So in this blog entry I will explore the decision making process of non-software product development teams.

The first source I turned to when during the many sleepless hours I encountered due to jet-lag was Hirotaka Takeuchi’s and Ikujiro Nonaka’s article entitled “The New New Product Development Game.” It was published by the Harvard Business Review in 1986 and studies six successful product development efforts (2 copiers, 1 car, 1 computer, and 2 cameras) which used a “rugby” approach to product development. This seminal work indirectly laid the groundwork for what was later to become the Scrum methodology. In this article Takeuchi and Nonaka identify six characteristics exhibited by leading product development companies:

1) Built-in instability
2) Self-organizing project teams
3) Overlapping development
4) “Multilearning”
5) Subtle control
6) Organizational transfer of learning

Three of these characteristics directly relate to the decision making process of the organization. Built-in instability is created by top management laying out a broad goal and giving the project team great freedom in realizing that goal. This creates a state of tension which necessitates that the team self-organize to reach its goals. Takeuichi and Nonaka assert that a team possesses the capability to self-organize only when it exhibits three conditions: autonomy, self-transcendence, and cross-fertilization. Management then applies subtle controls to guide the autonomous, self-organizing team, in the product development process.

Likewise, Taiichi Ohno in the book “Toyota Production System” compares the decision making process at Toyota to the nervous system of the human body. Just as many functions are performed automatically by the body without conscious decision by the human brain, so too are many decisions made at Toyota production plants made autonomously, at the lowest level possible, without having to seek the approval of a central decision making body.

But as the Toyota Production System (TPS) is geared towards manufacturing processes it is perhaps even more pertinent to consider the Toyota Product Development System (TPDS) which concerns new product development. Mary and Tom Poppendieck in their book “Implementing Lean Software Development” characterize product development as a knowledge creation process. They point out four cornerstone elements of the TPDS:

1) System design by an entrepreneurial leader
2) Expert engineering workforce
3) Responsibility based planning and control
4) Set-based concurrent engineering

At Toyota the chief engineer functions as the entrepreneurial leader mentioned above. He is responsible for the business success of the product and oversees the system design. It is interesting that for Toyota, in the development of highly technical products, it is an engineer who integrates the concerns of the market with the technical capability of the team. The remaining three elements of the TPDS really have a lot to do with distributed, responsibility based decision making process. Although the chief engineer sets the vision for the overall product, individual teams are given great freedom and responsibility to deliver at regular synchronization points. They explore design spaces through a process of gradually narrowing available options (i.e. set-based engineering) deferring making decisions until they absolutely must be made. In this way decisions are made at the lowest level possible, similarly to the TPS, with the vision, scheduling, and arbitration provided by the chief engineer.

Alistair Cockburn offers two interesting perspectives on decisions and decision making in team design activities (in the general sense, not just software). First, asserts that a key flow in design is the flow of decisions from person to person. These decision can be explicit decisions or decisions implied in the creation of a work product. He further characterizes unverified decisions in terms of lean as in-process inventory. Inventory, both in-process and completed, is a type of Muda (waste) in lean thinking. Decisions made but not verified by incorporation into the product and acceptance by the market represent a cost investment which is not yet generating revenue. Worse even then diminished profits this additional inventory can have a negative impact on the throughput and cycle times of the system. And lastly, the value of these decisions erode over time as market conditions and the product evolve.

Cockburn also offers a look at the decision making process in terms of the theory of constraints (TOC). In the decision making flow of design activities, there are dependencies between steps. These dependencies are analogous to the dependencies between stations of a a manufacturing process. As such a design process is subject to local optimization and bottlenecks in the same way as a manufacturing process is. TOC recommends a methodology whereby constraints are identified, production is leveled across stations, constrained stations are reinforced, and the capacity of the constrained station is elevated. In terms of the decision making flow in design activities this roughly equates to making decisions at the latest “responsible moment” and encouraging team members to assist in the decision making process of constrained activities (i.e. requirements determination, test, etc.).

I think that the ideas presented earlier by Takeuichi, Nonaka, and Ohno complement this model very well. The product development process (modeled as a decision making process) can be most efficiently balanced by autonomous teams self-organizing to define and optimize the system as a whole. Organizations which rely on a top-down decision making process are introducing bottlenecks into the process thereby disrupting flow, stifling creativity, and interfering with the self-transcendence of highly productive, collaborative teams.