FAQ: Is handing off to a tech team agile?

Posted on August 22, 2022.
positive businesswoman doing paperwork in office
Photo by Andrea Piacquadio on Pexels.com

We’ve talked about the many benefits of cross-functional teams often on this blog. We make a big assumption though that your company is structured in such a way that building a team consisting of product management, design and software engineering is possible. I work largely with enterprise-scale companies. More often than not these organizations have centralized “IT” functions that take care of much of the back-end software development and operations work. In these situations building a truly cross-functional team that can design, develop, deploy and operate their product is largely impossible. There is a handoff to the “tech team” at some point. Is this an obstacle to the agility of the organization? 

Handoffs slow us down

Whenever we have to hand off something from one group to another during the product development process we reduce our efficiency. The team has to document their work thoroughly. They have to then explain their work to the team receiving it. They have to answer their questions both at the time of handoff. And, of course, questions don’t stop just because the handoff is over. Finally, the priority the team handing off had for the work isn’t necessarily the same priority the receiving team has. This is particularly risky because so many of the assumptions built into the work will deteriorate over time. By the time the receiving time starts work, its current state may not be as effective as it is during handoff. 

Handoffs stop the learning process

There is another risk to explicit handoffs to another team in the organization – fixing the state of the work. As soon as the work is documented and that document (PRD, DRD, BRD, xRD, etc) receives a “_FINAL” qualifier in its file name, the team that did the work up until this point can no longer make changes. For them, their work is “done” regardless of whether their feature ever gets shipped or has a meaningful impact on its users. At this point no more learning is done about the product being built. The receiving team – often the “tech team” that has to implement the feature – is generally happy about this. They have detailed specifications, perhaps even a deadline and a clear goal – works as designed. It’s at this point that we’ve lost the agility in the product. 

This is not to say that no more learning will ever take place with that product (though the prospects are grim, let’s be honest). Perhaps, once it’s been in production for several months or more, the original team will take another look at it to see how it’s performing. The problem is that many markets don’t move in months-long and year-long cycles. They move more quickly. The handoffs required by these enterprise teams remove their ability to sense and subsequently respond to insight from the market. In fact, they’ve probably moved on to another project at this point. As the team loses its ability to adjust course based on learning, the organization becomes that much less agile in its ability to react to continuously changing market conditions. 

How can we mitigate the problems handoffs create?

Most of us don’t work in a position that allows us to redesign our entire organization. In these cases, what can be done to reduce the challenges handoffs to other teams create and increase both the likelihood of success for our work and the agility of the organization? Here are 3 ideas:

  1. “Borrow” a member of the receiving team – over the course of the first team’s work consider having a member of the receiving team join them on a consistent basis. This doesn’t have to be a full-time assignment. Perhaps they attend iteration planning meetings and retrospectives. Maybe they only attend stand-ups or perhaps we create a special “transparency” meeting just for this person so they’re aware of what we’re doing, why we’re doing it and what goals we are ultimately trying to achieve.

  2. Hand off smaller chunks of the product – instead of handing over the entire product design and development detail work with the IT team to hand off slices of the product. Get an MVP out to market quickly as you continue working on the next slice of functionality. In this way, both you and the IT team are busy and we have something in the market collecting data and impacting the ongoing work while it’s still in development.

  3. De-risk the product and design as much as possible prior to handoff – if the handoff to IT is indeed the death knell of product discovery for this work consider over indexing on that discovery work. Spend more time than you normally would testing, iterating and validating your hypotheses. This way, when the handoff takes place, you’ve got as much confidence as possible in the specified requirements. Stress to the IT team that your validated hypotheses won’t stay that way forever in an effort to ensure a high-level of prioritization for that work. 

Being agile is changing course based on evidence. To be agile we make two big assumptions. The first is that we are in a position to continuously collect evidence about the work we’re doing. The second is that we will have the opportunity and approval to make the changes we’ve learned from the evidence collected. When we have to hand off our work to another team we invalidate both those assumptions especially in the short term. We reduce the agility of the team and the business. There are ways to mitigate this but, in the end, these are just band-aids for a organization that should be implementing truly cross-functional teams.