When a company looks at nearshoring (or offshoring, but I obviously recommend nearshore) they’re faced with the question of whether to integrate the nearshore teams into their existing teams or whether they should create independent teams that work autonomously. There are some benefits to both approaches, but there are some recommendations that influence which approach is better for a particular project and a particular company.

Integrated Nearshore Teams

The model for integrated teams is to take a few people – potentially in a “staff augmentation” model – and add them to an existing team. It could be that the team is small and needs some additional skills. Or that a project requires more than the current team can deliver. Whatever the need, your team needs some help.

When you have a team that has any remote members, you should treat that team as fully distributed. The team should interact as if they were all remote. That ensures that everyone stays connected in the same way. And in this kind of a model, having teams that are “temporally co-located” (meaning in the same or similar time zones) is critical. It’s incredibly difficult – if not impossible – when a team member shares only a small part of the workday with the rest of the team.

There are a couple of key factors in determining when to use integrated team members.

Knowledge Sharing

The main benefit of integrating team members is for knowledge sharing. This helps any agile team build the skills that we want in “” team members. A breadth of knowledge in various technologies and techniques with significant depth in a few areas.

This is also key when you’re creating new technologies or using a technology stack that’s unusual or unique. Working together can help get your remote team members get up to speed quickly. Integrating team members doesn’t necessarily mean “pair programming” or even “collaborative programming”, but I would certainly recommend either of those if you want to see some early wins with new team members.

Just a Person or Two

The other time you’ll want to consider integrating remote members is when you’re just adding one or two people to a team. Establishing an independent team of one or two people doesn’t really work, so if you just need a couple of additional people, integrating is definitely the way to go.

But what if adding those two people puts you over the “? Honestly, it will be fine. You may need to discuss and see if it makes sense to shift to two smaller teams, but have that conversation with the team. The “” may still apply, but if you’re that close to the limit, I wouldn’t worry about it. There are plenty of examples of very successful ten- and eleven-person teams out there.

Same or Similar Time Zones

The key factor in making an integrated team operate successfully is ensuring a similarity in working times. Having a team member who shares less than two hours a day of overlapping work time will make the above situation very difficult. There are examples of this working – Scott Berkun’s describes this in his , for instance – but those companies have other ways of addressing this shortcoming. If at all possible, avoid the complexity that having people in radically different time zones presents. You’ll save yourself a lot of trouble – and keep a lot more hair.

Independent Nearshore Teams

The other option for creating teams – and it’s quite common – is that of independent nearshore teams. These teams are relatively autonomous and responsible for delivering everything on their own. The business provides a Product Owner (or business stakeholder equivalent) and the vendor provides the team. Sometimes this includes the Scrum Master or similar role.

Independent teams are good when the team is using well-known technology and has good analogues for the product. It’s important that the team also be able to manage all of the steps, from design and development to validation and release. It may end up in someone else’s hands to finally give to customers, but the team should be as self-sufficient as possible.

The main exception to this rule is the Product Owner or Business Stakeholder. That person guides the delivery team by giving them the priorities, answering tough questions about how we’re making the product, and knowing when the product needs to be ready to release. It’s a tough job but critical to success. And having that person share as much working time with the team as possible will help the whole endeavor be successful. It’s rare that an independent team can handle this role.

@ Velocity

We’ve used a mixture of both kinds of teams over the years. Both models work and because we have offices in South America that overlap the US pretty well, we’ve been successful with both. More recently we’ve been seeing a lot more requests for independent teams. Not because of project work – which is where this would be most common – but because of our experience in agile. Product Owner is the only role on a team that we’re not staffing for some clients. We staff the delivery team, including development and QA, and bring in a Scrum Master on our side. This has proven very successful and we’re constantly looking to find ways to improve on the model.

Closing Thoughts

Determining whether to integrate team members into a distributed team or create wholly independent nearshore teams is one of the first questions an organization should ask itself. The success of the project – and the partnership – depends on making some good decisions. You can always change the path you’re on later, but if you can start off on the right foot, your odds of success are so much higher.

Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)