Working with distributed development teams brings plenty of challenges. Here we tackle 8 frequent practices we must avoid in order to get the best performance and ensure the project itself succeeds.
In the current context and 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 is 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 its specific business area, 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 when those teams increase their size or when adding more teams.
You might be wondering what those practices are and of course how to avoid them. Let’s take a look:
1. 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 — become part of the team’s daily life. While we may think this should not dramatically affect the performance of a team, let me tell you that it actually does. Why? It is not difficult to realize that people get constantly distracted in order to attend meetings instead of focusing on the work they need to do.
On top of that, many times these meetings do not resolve anything (especially when the discussion gets diverted or when there are no conclusions, action items, next steps, etc.), which frustrates people .
My advice here is 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 ensuring everybody receives the same message.
2. 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 (e.g., 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 supported by accessible documentation that needs to be updated periodically. This will give the teams a framework to 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 are impacted.
It is also essential to ensure the processes and methodologies are adopted and supported at all levels and on every single team.
3. Not handling team dependencies properly
One of the recurrent issues when having multiple teams working together in development is not handling their dependencies properly.
The involved teams should be in sync before, during, and after the implementation. In addition, each team must clearly define its scope and the integration points, including the contracts defined among parties. Plans should be aligned as well to meet deadlines. If these tips are not considered, you should expect to have a lot of delays, miscommunication, and friction among involved teams.
Check this out: Get the best out of working with distributed software teams
4. 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 make business decisions or define priorities/scopes. In the same way, the business side 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.
5. 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 hear about issues in 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, if any of these situations last for days, it will have an impact on 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 be 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, and number of teams, just to mention the main ones. What you should definitely avoid is not having any strategy at all.
6. 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 synchronization among teams, they will probably face the situation where you develop something that somebody else has already done. Even having good communication and being aware of the existence of this code somewhere may not be 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 to develop faster (and therefore be in better shape to meet aggressive timelines) and ensure consistency across applications.
7. 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 end up having different approaches implemented to solve similar things (even within the same solution/project/application) and a high price to pay whenever the time to fix those bad decisions comes.
Do not miss this: Geographically distributed dev teams: A challenge that’s worth it
8. Making key people 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 is actually 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 this, their availability is almost null which could cause some extra delays while somebody else is waiting for them. Additionally, since they usually concentrate most of their knowledge, they become ‘silos’. If that knowledge is neither documented properly nor shared with the rest of the team and the silo decides to leave the team someday, all of it will be lost.
FINAL THOUGHTS
Working with distributed development teams brings a lot of challenges that need to be overcome to get the best performance and ensure the project itself succeeds.
While the patterns mentioned above are commonly faced nowadays, the good thing is that most of them can be easily addressed. How? Easy. First, identify and consider them as key to success, especially in the long term. Second, assign them the right importance, so make sure to invest time in addressing them as early as possible. Finally, adopt the set of practices defined for that purpose without forgetting to review them periodically to make sure they evolve with the project as needed.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
