Waste #4: Handoffs

Welcome to episode four of our series "The Seven Wastes of Software Development." In episode one, we introduced the concept of eliminating waste from our software development efforts. Waste elimination can be traced all the way back to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System (TPS). This is how Taiichi Ohno, the father of the TPS, described its essence:

All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes. [1]

Read the other parts in this series:

• The Seven Wastes of Software Development - Introduction
• Waste #1 - Partially Done Work
• Waste #2 - Extra Features
• Waste #3 - Relearning
• Waste #4 - Handoffs
• Waste #5 - Delays
• Waste #6 - Task Switching
• Waste #7 - Defects

In this episode, I'd like to focus on "Handoffs." Think of this as any time that you pass work from one role to another, essentially relinquishing responsibility for it. I've done my part, now it's time for you to do yours. Some flavor of the following set of handoffs happens in development shops all over the world:

 

The Business Analyst documents the requirements, obtains "signoff" from the customer, and then hands the requirements off to a Designer or Architect. The Designer/Architect drafts a design for system components that will fulfill the requirements, often also obtaining "signoff" from some authority, and then hands the design off to Programmers. The Programmers take the design and implement it using a programming language, libraries, frameworks, etc. Once the code is "done" (often meaning written and compiled), it is "thrown over the wall" to the Testers who then execute some test plan, identify and file bugs, etc. In simple terms, this represents the stereotypical "waterfall" model for development.

Unfortunately, only so much can be successfully passed on through documents and diagrams. Inherent in any concept is a great deal of "tacit knowledge." Wikipedia defines tacit knowledge as "knowledge that is difficult to transfer to another person by means of writing it down or verbalizing it." To understand tacit knowledge and the difficulty of transmitting it, let's look at some examples.

The Poppendieck's relate the example of teaching your child how to ride a bike [2]. I have yet to do this (although it is high time my oldest dropped her training wheels), so I'd like to focus on another incident in my personal experience.

My 5-year old daughter asked me tonight how to blow a bubble with gum. How in the world do you explain that? How much tacit knowledge is involved? I mean, technically I could explain how to do it, but what are the chances that she could translate that into a successful bubble? Demonstrating it is pretty difficult too, given the fact that she can't see inside my mouth.

But that's exactly what's going on here with handoffs. We're losing the message bit by bit as it goes down the line. Did you ever play the telephone game as a child? How many "handoffs" did it take before "Johnny picked an apple from the tree" became "Johnny picked his nose by the sea?"

And now here's the kicker. The Poppendieck's suggest we take the conservative route and estimate that each handoff leaves behind approximately 50% of the knowledge we intend to transfer [2]. That means:

• 25% of knowledge left after 2 handoffs
• 12% of knowledge left after 3 handoffs
• 6% of knowledge left after 4 handoffs
• 3% of knowledge left after 5 handoffs

That means that by the time the testers get their hands on the project (in our example above), it's quite likely that 88% of the knowledge required has been lost! So, what do we do? Here are some ideas:

• First, simply try to reduce the number of handoffs. Find ways to integrate disparate teams that need to work together.
• Rather than fulfilling project roles via separate teams, use cross-functional teams. Create a single project team composed of analysts, architects, developers, and testers.
• Use high-bandwidth communication methods. A good pecking order: Face-to-face, telephone/voice chat, voice mail, email, documents.
• Appropriately document knowledge where necessary. Use wikis to encourage the evolution of your documentation structure to best fit the knowledge you're trying to document.
• Quicken your feedback loops. Shorten your iterations. Close the gaps.

That's all for this episode of "The Seven Wastes of Software Development." Stay tuned for the next installment: Delays.

 

References

[1] Ohno, Taiichi. Toyota Production System: Beyond Large Scale Production. Productivity Press, 1988.

[2] Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.