A problem that we used to have was that even when we had started adopting Agile principles at work, we still thought about the flow of work in a waterfall style. Generally, this wasn’t too much of a problem. Within the POD, we would have multiple tasks running at the same time and passing work from one stakeholder to another happened very naturally and didn’t disrupt anyone’s rhythm in completing the work.

As we started to increase the scope and scale of our objectives, the scope of the work increased with it. That’s when we started to notice issues with how we handed work from one stakeholder to another. Back when it was one subject matter expert giving a task to another subject matter expert, it was safe to make certain assumptions about processes we had agreed upon or the context the other person had. Now that we had started to work across PODs, we were also working cross-functionally more often. Someone on my POD would complete their portion of work, hand it off to a software developer on another POD with some notes, and then things would go silent. After a week we’d ask how the work was going, and the other POD member would let us know about blockers that had come up, competing POD priorities, or additional context they needed from us that they were waiting on.

These issues always came as a surprise to us after we had assumed the work was going to get done, given what we had provided. In a few meetings we discussed how we could close the open loops in communication and facilitate better handoffs. Our CTO was actually the one who provided the feedback that we hadn’t been thinking about it in the right way. The issue was with considering it a “handoff” at all.

Depending on your company’s product development department, a single objective may require bits and pieces to be completed by multiple PODs. In order to maintain momentum, you can’t just drop a task on another POD and leave. It’s similar to what I said about drive by management.

How do we set ourselves up for success?

To avoid these bad handoffs, the most important step is to have an aligned product leadership team. All the POD leaders should be meeting regularly to discuss their priorities for the week or for a 2 week sprint, so cross-POD work can be identified early. Once you know that something is coming from another POD, the leaders should work in close collaboration (really you should aim for close collaboration all the time, but this is probably your last opportunity to get it right before a bad handoff happens).

They should identify who is doing the work in progress, who will do the next portion of the work, any necessary context, where this work fits in each POD’s priorities, and if any delays would jeopardize the completion of the work. Make sure the stakeholders on each POD can easily communicate to each other in case additional blockers or missing context is discovered. This mode of close collaboration allows for work to be rapidly unblocked, and momentum can be maintained. I think we’d all agree that’s better than waiting until the next weekly meeting to find out nothing’s started yet.

Keep in mind which POD and which individual owns the Objective or the Key Result that’s being worked towards. They should have access to all the stakeholders to continue unblocking issues, and also to report on progress.

Wrapping up

If your product development team can maintain close collaboration, it can prevent the formation of information silos, and help improve communication across the department, in addition to improving the department’s leverage.