Handoffs Aren't Bad—Just Think of Cooks in the Kitchen
Some people are confused by the word handoff. They think it means people have not done their jobs and other people had to cover for them.
Sometimes that happens. But more often, handoffs occur when you bring people together in a complex project or program, and the coworkers deliver their parts to make it a whole.
Here’s one analogy: Imagine you’re a chef at a famous restaurant, creating a great dining experience for your customers. You have the meat chef, the potato chef, the vegetable chef, the sauce chef, and the lead chef, all bringing the dinner together for the customer’s delight.
Not all meals need a lead chef, but sometimes they do. If you're working with a new team of people who don’t know how to perform their tasks, the master chef needs to show them the first few times how to put everything together. He’s not command-and-control. Does this sound to you like some new-to-agile teams working with a coach? The coach isn’t a master chef. The coach is a facilitator. It’s a little different.
The person in the master chef role asks each chef to hand off their parts to the plate. (In effect, this means integration to the software people.) As master chef, he would do the clean-around-the-outside-of-the-plate thing that master chefs do, add a sprig of herbs, and hand off the plate to the server, so now the plate goes to the diner for a delightful culinary experience.
As the people in the kitchen evolve in their work, they don’t need the master chef to supervise them. They become a self-organizing team that can do this on their own. But they still have handoffs because the meat chef still focuses on meat, and the potato chef still focuses on potatoes, etc.
In kitchens, chefs are trained to be generalizing specialists. In software, we aren’t always trained. But we can learn if we want, and we can pay attention to the handoffs.
In an agile team, especially with continuous integration, we don’t notice handoffs. Continuous integration makes handoffs trivial. If we work together to achieve a feature, as in swarming or mob-programming, we don’t even have handoffs.
In a non-agile environment or when you don’t have software, we want to know when the handoffs occur so the team can synchronize around them. In a geographically distributed team, we want to highlight the handoffs so we know what to expect and when.
Handoffs aren’t inherently bad. It’s how we manage them that can make them good or bad.
