The more handoffs that are required by a process or organization to do its business, the less effective that process or organization is. Said another way, there is an inverse correlation between handoffs and high performance.
I think I first realized this in kindergarten, when Miss Fiskerbeck played a game with us one day: She had the class stand up in a line, whispered something to the first kid in line, and then told him to pass the message along in a whisper to the next kid, who would pass it along again. When the message reached the last kid, he was to say the message out loud. As a mode of communication, this method had significant drawbacks, one of which was that it took time for the message to propagate to its destination. But far worse was the distortion that took place: the message that emerged at the end bore no resemblance to the original, because it was translated and interpreted over and over, each time it was handed off.
That silly little children’s game illustrated something that we still suffer from as adults in a business environment: we create organizations and processes with many boundaries among them. Each boundary requires a handoff. Every handoff introduces delay and distortion.
Most development people have seen this cartoon at some point, and no doubt can relate to it because we’ve all seen it happen:
Every time the original piece of information is handed off from one independent organization to another it is subject to further (mis)interpretation. Even worse is the fact that most handoff-oriented processes do not include any form of feedback loop to prevent distortion from accumulating. Can you imagine how the outcome might have been different if only the customer had been shown a sketch of the proposed swing at each point in the process?
So what’s the lesson?
- Minimize the need for handoffs in your organization or process. Each handoff is bad because it introduces delay and distortion.
- Because it will not be possible to eliminate handoffs completely, be sure to incorporate feedback loops in each step to minimize distortion.
OK, the theory is great, but how can this be addressed in practice?
First you need to understand where the handoffs occur. In whatever you are doing, make a quick sketch that shows each distinct participating organization, and arrows to show the process flow across these organizations. By “organization” I mean any group or individual that operates with some degree of autonomy as a team. Traditionally an organization is defined as a group of people under a single manager or leader, because typically each one operates somewhat independently with its own goals. On your sketch, every time a process flow line crosses an organizational boundary you have a handoff of some kind, but there could even be handoffs within an organization.
Now finally we come to the punch line for development: The traditional waterfall process practically enshrines boundaries, as work progresses sequentially from product managers who collect requirements and define product strategies, to analysts who create product specifications in response, to engineers who build software that attempts to meet the written specifications, to QA who tries to figure out if the code works. Each group is whispering sequentially in the ears of the next group in line, and we know what that causes.
Note: In software, interface boundaries between systems are common so we might be tempted to use such interfaces as an example of how handoffs should work across human organizations as well. But humans don’t work like computers. The information transmitted across software interfaces is usually concise, structured and factual, while the information conveyed in a handoff between human organizations is verbal, complicated and not well structured. Obtaining a “signoff” at each handoff does little to prevent distortion or ambiguity because every document ever written is subject to interpretation (hence the existence of lawyers).
Part of the answer to this is to use an agile process such as iterative and incremental development. Why does this help? Most obviously, it provides a feedback loop. At the end of each iteration, the resulting code is publicly demonstrated (even to customers) so everyone can see how the product is shaping up, and corrections can be made in subsequent iterations. Long before delivery the customer can see that the swing is not suspended in the air, and that isn’t going to work, so it needs to be corrected in a subsequent iteration before delivery.
But iterative development alone is not enough! There are several other essential elements of minimizing handoffs in software development:
- Cross-functional development teams. I have blogged on this before. Development teams must be organized cross-functionally, with the analyst, engineer, and QA person working together as a team, and NOT doing their work sequentially. This alone eliminates several of the handoffs that exist in the waterfall process.
- Product Management must be tightly engaged as part of the development process, and must not stand apart as outsiders. They must act as and be treated as part of the overall development team. There cannot be any gap between Product Management and Development. Many product organizations have a big gap between these two groups that is caused by the organization structures and apparently by tradition, and I firmly believe this gap causes the biggest handoff issues in the whole development process. Product Management must be part of the feedback loop, and must be strongly connected with the daily development operations. This can be done, and is being done in some product organizations.
Handoffs are bad. Teamwork is better.
