The handoff, the process of passing a software development project from one team to another, is one
of the more quietly problematic parts of the development process. A poorly executed handoff can
cause delays, affect product quality and, most significantly, allow bugs to escape detection.
Many development processes require a handoff at some time, whether the project is moving between
architects, product managers, developers, QA testers or maintenance groups. At Spark Digital, we opt
for cross-functional teams (which combine product management, architects, coders and testers) to
reduce the need for and impact of handoffs.
We do, however, find ourselves handing over products to external maintenance teams (often back to
our clients), and while every handoff carries risk, a couple of simple principles can help your team
account for this risk and execute the process seamlessly (or as close as we can get in development).
This means that a handoff should never happen ad-hoc (to address a specific issue subordinate to the overall development process) or otherwise disconnected from a product’s development lifecycle. It is an engineering task with formal underpinnings. By communicating that importance of the handoff, teams on both sides are able to better integrate the transition into their processes. This principle has direct ramifications for overall project effort estimates. Handoffs must be built into the project timeline and budgets, and should never be executed on a “best-effort” basis or on goodwill (after hours or “when we get some free time”). This approach ensures that all parties avoid the trap of assuming the handoff is primarily the other’s responsibility.
1. Diagnosing new issues alongside with the new/old team 2. Peer-programming bug fixes or new features (if any small ones exist) 3. Peer-releasing new code to Staging and Production environments 4. In the case of a development-to-maintenance handoff – Letting the maintenance team deploy a complete version of the system (spin out servers, deploy code, run smoke tests, etc.) It can’t be a handoff without some hands-on, so the awful pun goes. And, as any good manager knows, telling is not nearly as effective as showing (and verifying demonstrable knowledge, in return). That is why we recommend an 20/80 split in terms of handoff priorities. During a handoff, spend about 20% of the time reviewing the product’s high-level architecture, essentially communicating the big picture, and about 80% of the time doing some or all of the following activities: During a handoff, you must get buy-in from all parties involved. Everyone must acknowledge that handing over a project is not overhead. It’s an important stage of the development lifecycle, as important as defining user stories, coding and testing, and be full participants in the process. Only with complete buy-in (Principle 1) will you be able to properly pass on product knowledge (Principle 2). Additionally, ensuring that you have systems that facilitate open communication and properly document knowledge are necessary to supporting both of these guiding principles.
The Bottom Line
During a handoff, you must get buy-in from all parties involved. Everyone must acknowledge that handing over a project is not overhead. It’s an important stage of the development lifecycle, as important as defining user stories, coding and testing, and be full participants in the process. Only with complete buy-in (Principle 1) will you be able to properly pass on product knowledge (Principle 2).