Genchi Genbutsu Communication is one way to prevent communication breakdown.
I’ve written previously about team dynamics and team size. I’ve since modified my feelings regarding those previous claims.
Here is what I said previously:
- 2 people are smarter than one
- 3, 4, 5, 6, 7, 8 people are smarter than 2
- a team larger than 9 people is just one big dumb blob
Ok, that’s not true at a wholesale level, but it sure feels like it. A small team with highly smart and capable team members can do much more than 10 mediocre team members. The Wisdom of Crowds mentality doesn’t work that well when it comes to efficiency in teams.
Quantifying Communication Breakdown
A more quantitative explanation is as follows:
One of the root causes of failure in projects is communication — either a lack thereof, or miscommunication. Large teams are inherently vehicles for bad communication. This is basic combinatorics — for a given project, suppose there are persons A and B. In this scenario there is only 1 communication link. Add person C, now we have 3 communication links, A-B, B-C, C-A. Add person D, then we have 6; Add person E, then we have 10 communication links. Inductively, as team size grows, the raw combinatoric communication link counts grows geometrically, not linearly. To demonstrate this, we use basic statistics of the form n-choose-r, where !, such as n!, is equivalent to n factorial, to arrive at the formula for how many pairs we can choose from n items:
For the number of pairs, we can reduce the above formula to the following:
Visually, as team size grows, the communication links grows non-linearly, but exponentially:
My True Position
Do not let the above dissuade you from large teams; if the product requires a large team, then that is what is needed. Caution, is what I am arguing here. The facts are that the larger the team, the more communication channels there are and the entire process then becomes more error-prone. If the product requires a large team, then expect the above challenge and manage it. One effective way of managing large teams is the Obeya.
“Obeya” means “Big Room”. In the Toyota Product Development System, there is a concept of a “War Room”, where the entire product, cross-functional team meet daily. The reason for this is to shorten the Plan-Do-Check-Act (PDCA) cycle time, eventually leading to a quicker time-to-market. Obeya also attempts to break down walls between departments, and upper and lower management. Often times, Upper management is not involved in the dirt and sweat of projects or efforts, leading to uninvolvement and potential breakdown in communication or not getting buy-in until much later in the product or project lifecycel. In their words (Chemical and Engineering News, November 2003),
Toyota consistently tops the J.D. Power surveys and the secret seems to be as much in the employee training and product development process as in the production machinery. And that training has as much to do with company culture as it does with equipment and technique.
Behind the development process is Toyota’s “obeya” concept, which translates to “big room” in English. The obeya group is like a ‘cross functional team.’ But instead of weekly meetings, it is an ongoing session. The group would typically include engineers, design stylists, suppliers, assembly workers and members of our marketing team
“One of the ideas behind obeya,” says Niimi “is to shorten the PDAC cycle. In the concept of PDAC or Plan, Do, Check, Action, each part of vehicle development goes through certain steps – planning an activity…conducting the activity…checking the results…and acting on those results.
“In the past, each PDCA cycle would take weeks – with site visits, video conferences, and countless e-mails. But with obeya, there could be several PDCA cycles per day.”
For the development of Sienna, the concept was expanded and elevated to a much broader level. The obeya location was physically moved based on the development need, a “traveling obeya.” It moved from Japan to Ann Arbor, to manufacturing headquarters in Erlanger, Ky….back to Japan and then to Princeton, IN, where Sienna is built.
“The reason obeya works so well ” says Niimi, “is that it’s all about immediate face-to-face human contact. Also, new computer software enabled us to ‘virtually’ design and assemble nearly every component of the new Sienna prior to the production of a single prototype part.
“Thanks to this we were able to look at ‘ergonomic human factors’ from the initial design stage. The digital assembly software was so detailed and true-to-life that animated human workers were programmed to perform each assembly task.
“We gained a clearer, cleaner more accurate blueprint of how the vehicle would emerge from the assembly line. The result? Fewer changes, saved time and reduced cost.”
This cross-functional approach — horizontal as well as vertical team integration — alleviates the many problems that combinatorics teaches us about communication problems and breakdown. So, regardles of N-Connections as I argue above, Obeya can help manage the information flow by integrating vertically and horizontally as a cross-functional team.
In the creation of the Sienna, Obeya was used to bring decisions much earlier in the product lifecycle, ultimately bringing to car to market much sooner than anticipated, and thereby reducing the cost of the car by almost $1,000 USD (Chicago-Sun Times, February, 2003):
Toyota made extensive use of the “Obeya” or “Big Room” concept in developing the Sienna, bringing engineers, stylists, suppliers and assembly workers together to analyze all aspects of vehicle development. The resulting savings in development costs enabled Toyota to price the new minivan close to $1,000 less than the current model. Pricing on the 2004 Sienna ranges from $22,955 for the CE model to $36,930 for the all-wheel-drive version of the Limited, plus destination and delivery charges.
There is also research conducted by several research groups, showing the increase in productivity via Obeya:
“…having development teams reside in their own large room…had significantly higher productivity and shorter schedules… The teams reported high satisfaction about their process and both customers and project sponsors were similarly highly satisfied.”
Teasley, S., Covi, L, Krishnan, M. S., and Olson, J. S. (2002). Rapid software development through team collocation. IEEE Transactions on Software Engineering, 28(7), 671-683.
“Teams in these warrooms showed a doubling of productivity. Why? Among other things, teams had easy access to each other for both coordination of their work and for learning, and the work artifacts they posted on the walls remained visible to all.”
Teasley, S., Covi, L, Krishnan, M. S., & Olson, J. S. (2000). How does radical collocation help a team succeed? Proceedings of the 2000 ACM conference on Computer supported cooperative work, 339-346.
Daily Stand-Up Meetings, Sit-Down Meetings, Three-Up, Three-Down
In the past, what I’ve found helpful for product- or project-type teams is to have daily Stand-Up Meetings. These meetings are literally done standing in the Gemba or in front of the project board, then going around team-member by team-member discussing what they plan on accomplishing that day, any roadblocks, and lessons-learned or challenges they’d like help with. This Stand-Up Meeting should be done first thing in the workday and should be reasonably short, maybe 15 to 20 minutes. At the end of the day, I like to have a quick Sit-Down Meeting, again 15 to 20 minutes, where each person discusses Three-Up and Three-Down, which means 3 things they accomplished that day, and 3 things that were a bummer that day that they’d like to work on the next morning and any help, if needed.
These meeting should be short, but done regularly. The daily-ness of the meetings will add a dimension of regularity, progress, and enables frequent communication. Couple these scheduled meetings with informal meetings as needed.
Too bureacratic? I don’t think so. If the time requirement of 15 to 20 minutes is held strictly, then there most likely won’t be feelings of bureacracy or over-processing or over-scheduling.
Mitigating Communication Breakdown
Again, basic combinatorics teaches us that as the number of agents involved in a process increases, the communication links between those agents increases exponentially, thus allowing for a potentialy Nx communication-link breakdown. To manage that, scheduled but quick Obeya meetings can help, as well as as-needed informal meetings between individuals and groups.