Agile Teamwork: Three Ways to Minimize Handoffs

Teams using a sequential development process have become accustomed to handoffs between specialists. Analysts hand their work to designers, who hand it to programmers, who pass it on to testers. Teams that are new to Scrum often do not go far enough in eliminating these handoffs, wrongly assuming, for instance, that the programmers should finish programming a product backlog item before handing it off to the testers or that analysts should work at least one sprint ahead of the rest of the team.

High-performing Scrum teams, however, have learned to do a little bit of everything all the time during a sprint, thereby eliminating large handoffs. To do this effectively, teams must make three changes: favor talking over writing, make handoffs very small and very often, and mix the size of items that are brought into each sprint.

Stop Writing and Start Talking
There’s a grand myth about requirements: If you write them down, users will get exactly what they want. That’s not true. At best, users will get exactly what was written down which may or may not be anything like what they really want. As such, Scrum teams forego a lengthy, up-front requirements phase and the resulting product specification in favor of a dynamic product backlog.

Because Scrum teams shift focus from writing about requirements to talking about them, conversations with the product owner—rather than a product spec—become the primary way of finding out how a new feature should behave. Team members talk with the product owner about how a feature should work, how quickly it should perform, what acceptance criteria must be passed, and so on. Scrum team members also talk with users, customers, and other stakeholders as appropriate and, perhaps most importantly, with each other.

On traditional projects, analysts often act as intermediaries, communicating customer needs to programmers. On Scrum teams, however, analysts function as facilitators, ensuring that appropriate discussions between team and product owner take place. For instance, an analyst might steer the product owner and team toward talking about a particular user story because it has more risk than another of going astray. At other times, an analyst might convey a top-level understanding of a new feature to the team before bringing the team and product owner together to discuss the details. In all cases, analysts on Scrum teams foster communication rather than distill information through a document.

All of this is not to say we should abandon written requirements documents. Rather, we should use documents where appropriate. Experienced Scrum teams lean heavily on cleanly written code and automated test cases. They then augment these forms of documentation with a written requirements document only to the extent that such a document is helpful or required for regulatory, contractual, or legal purposes. As Tom Poppendieck, coauthor of books on lean software development, once told me, “When documents are mostly to enable handoffs, they are evil. When they capture a record of a conversation that is best not forgotten, they are valuable.”

Transfer Small Tasks Frequently
On Scrum teams, the unit of transfer between disciplines should be smaller than an individual product backlog item. That is, although there will always be some handoffs, the amount of work being transferred from one person to the next should generally be as small as possible.