In the current context after the pandemic, distributed teams across the world have become a reality and the software industry is not an exception to this. Regardless of the team’s configuration chosen for each specific case (in-house, offshore, or a mix of both), it’s easy to find so many examples where teams fail to succeed due to a wide variety of factors.

While each project has a completely different nature that is mostly related to the business area they are related to, there are some common patterns that get repeated frequently. Unfortunately, they have a negative impact not only on the team’s performance, but also on the success of the project itself. What is more, their consequences become exponential as long as those teams increase their size or even when adding more teams.

You might be wondering which those practices are and of course how to avoid them. Let’s take a look:

● Miscommunication and overcommunication

Calendars fully booked, meetings without a purpose/agenda, many attendees invited without any specific reason, calls scheduled to discuss stuff that could be addressed offline, multiple channels where topics get lost — just to mention some of them — became part of the team’s daily basis. While we could think this should not dramatically affect the performance of a team, let me tell you that it does actually. Why? It should not be difficult to realize that pe*ople get constantly distracted in order to attend meetings instead of focusing on the work they need to do.* What is more, many times these meetings do not resolve anything (specially when the discussion gets diverted or when there is no conclusion, action items, next steps, etc), which makes people frustrated about this. My advice here it’s simple: define the communication strategy you want to use and make sure everyone not only understands it but also follows it. This includes establishing which channel to use for each purpose, meeting only when needed, including the right audience, moderating meetings and channels, and of course ensuring everybody receives the same message.

● Not having clear methodology/processes defined

This comes in different flavors, but basically the idea is that everyone on any team should know how to proceed in most common situations (i.e how to track requests/issues, how to deploy, which branching strategy to use, which standards to follow, etc). In order to accomplish the ideal state, processes and work methodology must be defined and of course supported by accessible documentation that needs to be updated periodically. This will bring the teams a ‘framework’ which will make the work they do on a daily basis easier. Otherwise, it will be easy to end up in some sort of chaos where team performance, business expectations and timelines will be impacted.

It is also essential to ensure the processes and methodologies get not only adopted but also supported at all levels and on every single team.

● Not handling team dependencies properly

One of the recurrent issues when having multiple teams working together in development is not handling their dependencies properly.

Involved teams should be in sync before, during and after the implementation. In addition, each team must have clearly defined its scope and the integration points, including the contracts defined between parties. Of course, planifications should be aligned as well in order to meet deadlines. In case nothing of the previous is considered, you should expect to have a lot of delays, miscommunication and friction between involved teams.

● Confusing roles and responsibilities

While it is essential for the entire team to be involved in a project and engaged with the mission of adding value in different areas, It is important not to fall into the common trap of confusing roles and responsibilities. Developers are not supposed to take business decisions and/or define priorities/scopes. In the same way, “the business” is not supposed to be involved in implementation details. Not having a clear separation of concerns between parties may affect not only the project development itself but also the relationship between them.

● Lack of development & delivery strategies

A huge mistake is not clearly defining the procedures the teams need to follow in terms of branching techniques usage, environment deployments and releases management. A classic example of this is when you heard about issues on the environments where the applications get deployed to. This may cause some environments to be not usable at all due to errors, some others to be ‘frozen’ for some time or even entire features overridden in some specific environment by someone else’s deployment. What is worse, it may be the case that any of these situations last for days, which of course will have an impact over some other planned delivery timelines.

While the situations previously mentioned could happen due to several reasons, the truth is that in most cases, they could have been prevented by defining and implementing the policies to address them. The right strategy will depend on many factors such as project delivery requirements, infrastructure resources, available budget, amount of teams, just to mention the main ones. What you should definitely avoid is not having any strategy at all.

● Reinventing the wheel many times

This one becomes more visible especially when having lots of teams working at the same time in different applications that belong to the same ecosystem. It refers to the fact that without good communication and sync between teams, they will probably face the situation where you develop something that somebody else already did. Even having good communication and being aware of the existence of this code somewhere, it could be not enough. Here is where the importance of having reusable code and the right infrastructure to support it, becomes essential. By doing this, your team will be able not only to develop faster (and therefore be in a better shape to meet aggressive timelines), but also to ensure consistency across applications.

● Not handling the teams autonomy properly

While the autonomy of each team is a great asset and something we should look for, this does not mean anarchy. In other words, each team cannot do whatever they want just because they consider it is the right way to do something. Team strategies, implementation designs and technical decisions must be reviewed and validated with other teams, especially in those cases when -at the end of the day- all of them are working under the same ecosystem. If not, you will not only end up having different approaches implemented to solve similar things (even within the same solution/project/application), but also a high tax to be paid whenever the time to fix those bad decisions comes.

● Making key people to be ‘bottlenecks’ and ‘silos’

We all want the key players to be part of our teams. They usually bring smart solutions, have the knowledge to make things work and are an essential piece to succeed. Nothing wrong with that right?

The problem is that they usually become a bottleneck in many ways, which actually is an issue. Basically, they get involved not only in almost every tech discussion (even from other teams), but also in several other decisions (including not technical ones). Because of the previous, their availability is almost null which could also cause some extra delays while somebody else is waiting for them. In addition, since they usually concentrate most of the knowledge, this is why they become ‘silos’. In case that knowledge is neither documented properly nor shared with the rest of the team, it would be lost if the ‘silo’ decides to leave the team someday.

FINAL THOUGHTS

Working with distributed development teams brings a lot of challenges that need to be overcome to not only get the best performance from them but also to ensure the project success itself.

While the patterns mentioned above are commonly faced nowadays, the good thing is that most of them can be easily addressed. How? Easy. First, identifying and considering them as key to success especially in the long-term. Second, assigning them the right importance they have, so make sure to invest time on addressing them as early as possible. Finally, adopting the set of practices defined for that purpose, without forgetting to review them periodically to make sure they evolve as needed as the project does.