Mary Poppendieck has just published a presentation on Agile software development entering the mainstream (and how to fail with agile). The presentation contains a number of insightful key points, but one footnote struck a chord with me: According to Allen Ward’s “Lean Product and Process Development”, Handsoffs are the biggest waste of product development. This has long been a pet peeve of mine, and I want to examine why handoffs occur, why they are expensive and how to avoid them.
Poppendieck writes “a narrowly focused team requires handoffs at the boundaries.” Furthermore, handoffs occur when we separate responsibility, knowledge, action and feedback about a task. My experience is in agreement. As a vivid example, my project once had the responsibility to get our software accessible through the company extranet portal. However, separate teams had to make changes in network, webserver and security configuration. These teams had imperfect knowledge of what information should be exposed, and so we had to spend about a week describing changes in detail. When the changes were performed, a mistake I had made in a hostname in the configuration of the web server had only been corrected in two of three documents. The web server team used the third document as basis for their work. And the feedback on the success of the change was left to my team, who found out that it didn’t work the next day. This single letter typo that I made in our documentation cost our project two days worth of progress.
With this sort of separation between responsibility, knowledge, action and feedback, it is surprising that we get anything done at all. This is a testament to the dedication of all parties involved.
How can such costs be reduced? The knee jerk reaction is to blame it on my mistake. I should’ve checked my documentation better, or even better: I should’ve had someone else checking my documentation. This sort of reasoning misses the real point. The change in the web server was four lines of simple configuration changes. We knew what to do, doing it was trivial, and we had already spent days documenting it.
Eliminating the waste of handoffs requires both proper design and knowledge. I could’ve made the change myself, but I didn’t have access to the systems in question. In this case, this might’ve been a reasonable restriction, as a mistake could’ve taken down the whole extranet portal, not just our application. In many situations, a solution could be designed which reduces the risk of mistakes when changes are made. The number one way of reducing the risk is through isolation. If we only can affect our own project’s success, the preferred situation should be for us to make the change instead of handing it off to another team.
The second barrier to eliminating handoffs is knowledge. I have made it my business to ever expand my circle of knowledge regarding the systems I work on. I have control over the operating system, supporting scripts, operations, databases and other related software. But acquiring the necessary knowledge takes time, and most people want to reduce the amount of time outside their job that they have to spend learning. Ultimately, it must be the responsibility of the organization to give people enough time to master not just the narrow focus of their primary job, but a constantly widening understanding of the system and business as a whole.
The interesting question is: How much learning time will a team need to eliminate wasteful handoffs? I think the number will be discouragingly high. But the ever growing cost that comes from handoffs and overly specialized division of responsibilities will ultimately cost much much more.
