How agile teams can minimize hand-offs

Hand-offs—when one team needs to wait for another to complete some work—are all too common in software development, including in agile environments. And the more frequently hand-offs occur, the more detrimental they are to your team's productivity.

Hand-offs are the corporate reality of today; they are not specific to agile teams. But doing too many hand-offs means you can't ship software quickly. You face wait times each time you request that an item be added to the backlog, assigned to a resource, and so on. So it's imperative to minimize, or eliminate, hand-offs if you want to deliver quickly.

High-performing Scrum teams can mitigate the pitfalls of hand-offs by applying the right strategies at the right time. Here are some of the problems agile teams face with regard to hand-offs, and four strategies that you can use to mitigate them.

World Quality Report 2018-19: The State of QA and Testing

Are hand-offs really that bad?

A high-performing agile team should ideally have few to no hand-offs. Fortunately, there are several strategies you can use to efficiently eliminate all consistently slow hand-offs. Typically in agile, a sprint is two weeks. There is no generic number to denote a slow hand-off, but any hand-off that takes more than two days in a sprint is considered slow.  

With every hand-off, tacit knowledge gets lost, because it is very difficult to make tacit knowledge explicit.

Here's the problem: In a typical agile team, analysts pass their work to the developers, and the developers in turn pass it on to the testers. 

One standard practice is that the developers or programmers complete their development work before handing it over to the testers. These teams have the view that analysts should plan one sprint ahead of the team, and that's it.

There are situations when development teams must pass work from one role to another, relinquishing the responsibility for that task. Such hand-offs are common in development shops, but high-performing Scrum teams should do anything they can to reduce these hand-offs.

How to minimize hand-offs

There are four strategies you can use to reduce the number of hand-offs in agile:

  • Building a better communication structure
  • Minimizing the loss of knowledge
  • Being more transparent
  • Sizing your teams appropriately

1. Improve your communications structures

I worked with one agile team in India that was cross-functional and co-located in India and abroad. The team had 20 members; most of them were full-timers, and four of them part-timers. This team struggled with frequent hand-offs, and communication among the team members was restricted to one location.

These are the steps I took to help improve communication among the team members—and they worked like a charm: 

  • Define roles, responsibilities, and goals at the start of every sprint.
  • Encourage queries from each team member.
  • Conduct retrospectives at the end of each sprint.

2. Minimize loss of knowledge

With every hand-off you lose some tacit knowledge, because it is difficult to make tacit knowledge explicit. Sequential development activities represent a stereotypical waterfall model for development.

One way around this is to cross-train the agile development teams. High-performing teams should know a little bit of everything that is needed in a sprint, since this eliminates time that is otherwise wasted in hand-offs. Each team member in an agile team should be aware of the technology and tools being used, as well as the technical intricacies. It doesn't mean that a team member should be expert at everything, but he or she should at least be aware of it.

3. Share knowledge and be transparent

The success of a team depends largely on shared understanding, knowledge, and collaboration. In the quest to build high-performing teams, don't alienate yourself from your team members.

When you are sharing understanding among your team members, you should share the context as well. It is imperative that your team be aware of the bigger picture. This will give you much more transparency when influencing your team, and the team will also be aware of the shared goal it needs to achieve. 

The team leader should share the corporate goals and what needs to be achieved by the team for the project/product and any milestones that need to be hit.

4. Size teams appropriately

While there is no hard rule on what the size of an agile team should be, you need to ensure that there are minimum dependencies on other teams. A small team is not about the number of members; rather, it's the team's autonomy, the cross-functionality, and the degree of collaboration that matters. 

That said, I've worked with many high-performing teams that had few to no hand-offs with other teams. While these teams were autonomous, cross-functional, and co-located, they were also well-versed in agile management, planning, testing, and development. And most importantly, they were motivated, and they had the ability to be fast learners and to adapt to new tools and technologies at the drop of a hat. 

There is no magic number; team sizes should typically be six, but I've seen teams with as many as twenty members do great work.

I've seen one autonomous, cross-functional, co-located team deliver much faster than multiple small teams that offload work. However, to minimize or eliminate hand-offs, you need to have the right people with the right mindset. It's up to you to build this culture in your team. 

Focus on goals, objectives, and culture

Success is not only about meeting well-defined goals and objectives. Success itself should be a culture. Success will follow if your team is adept at understanding and practicing these principles: The ability to learn and adapt quickly to new and emerging tools and technologies, share knowledge, be transparent, collaborate, be honest, and have integrity.

Let success be the culture—it should be the way of life in your team. That's what success is all about, isn’t it? 

Topics: Dev & Test
Article Tags