Handoffs are Not a Bad Word
Handoffs are Not a Bad Word
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
I had a great conversation last week with someone taking a leadership course. (Not one of my courses. His instructor wouldn’t talk to him!! He’d seen one of my posts and emailed me. Of course I talked with him.)
He was confused by the word “Handoff.” He thought it meant that people hadn’t done their job 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 they deliver their parts to make it a whole.
Here’s the analogy I created for him during our conversation. 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 you, the lead chef, all bringing the dinner together for the customer’s delight.
Not all meals need a lead chef, but sometimes they do. In this example, they do. Why? Because my colleague has a new team of volunteers who don’t know how to perform their tasks. He is the master chef. He’s not command and control. But he needs to show them the first few times how to put everything together. Does this sound like some new-to-agile teams, working with a coach, to you? The coach isn’t a master chef. The coach is a facilitator. It’s a little different. Okay, back to our example.
My colleague, in his role as master chef, asks each chef to handoff their parts to the plate. (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, handoff the plate to the server and now the plate goes to the diner for a delightful culinary experience.
As the people in the kitchen evolve, they don’t need the master chef to supervise them, do they? No, they become a self-organizing team who can do this by themselves. 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. 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 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 bad. It’s how we manage them that can make them good or bad.
Published at DZone with permission of Johanna Rothman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.