Successfully delivering with multiple teams

Communication, communication, communication… One simple word, one huge challenge. When delivering a software project that involves multiple development teams, I believe that communication is the key to success. Disconsidering or underestimating the time zone, the cultural and mindset differences or the different ways of working can potentially harm a project. Or even break it.

Premises

Project: the implementation of theopen.com
Teams involved: the development team from Delete, and the TEC team, in charge of managing the application once it was launched on production.

Mapping the process – key points to consider

Branching strategy
How do we merge the code of the two teams that are essentially implementing two totally different types of tasks? While the Delete team was implementing new functionality, the TEC team was implementing fixes, offering support to the live product, and bringing improvements to the website. In this case the branching strategy was very important, as it was crucial for all the developers to follow the agreed strategy. Branching allowed our developers to collaborate fluently in the main code base.

Handover and deployment process
How do we deploy to production a piece of code that was not implemented by us, but needs to integrate perfectly with our fixes and/or improvements? We did that by a well-documented handover and deployment process, which helped us integrate the 2 teams’ functionalities.

One Jira Board – visibility on each other’s task management system
At first, two different teams meant two separate Jira boards. We literally had no visibility on what the other team was implementing. A couple of code merges went wrong, no big news there.
We thereby implemented a common Jira board – allowing both our teams visibility and easy access where help was needed. Communication and access were the keys in order to turn this whole story into one coding team, dedicated to successfully delivering the project.

Setting the ground – clear roles, responsibilities and goals of the 2 teams – right from the beginning
It is crucial for both teams to have a deep and accurate understanding of what the other team is responsible for. Usually, the team that is responsible for the development of a website, without needing to offer support on that product, will not know the struggles and problems the support team is facing. On the other hand, the support team will not always have all the business knowledge of the development team nor the time to code by the highest standards. This sets the scene for a conflictual relationship between the teams right from the start. It is very important to point this out as early as possible and deal with it as soon as possible. Unfortunately, we missed this part when we started working together with the Delete team, but during the retrospective meeting, we realized that everything would have been much easier if we would have set the grounds right from the beginning. I would say that this was one of the greatest issues we faced during the first part of the project.

Centralizing our efforts – constant communication between developers
At the beginning of the project, we considered 2 separate teams, but in time we realized that we definitely need to work as a single team. Once we achieved this, everything went much smoother.

Bridging the gap – face-to-face meetings between developers
Working in software development, we often underestimate the value of the human factor and the value of building relationships. Given the space/time distance between us, this was a bit harder to achieve. Nevertheless, we made it possible for the Delete team to have multiple visits to Cluj. All it took was a face-to-face meeting – all the frustration, the misunderstandings, the fear of “what will others think” have disappeared. They had a better understanding of what our needs are, why are we pushing for certain processes to be in place. At the same time, we understood their point of view, their deadlines, their necessities.

Common best practices regarding coding
Although there is a general best practice in coding, which is applied by all developers around the world, usually every company has their own coding style, internal best practices and tools they use. While working together with the team from Delete, we found that is quite easy to set common grounds, as long we communicate and explain the other party why are we implementing certain things in certain ways.

The Aftermath

Where there things we could have done better? Yes.
Where there key points that created misunderstandings, probably a bit of frustration and waste of time at certain points? Sure.
Did our project turned out great? Hell, yeah!

As teams come together into one common project, challenges are inherent. Dilemmas are inevitable.
Are there secret ingredients that can turn things around?
The all-time secret is constant communication. Besides that, overcoming difficulties throughout dialogue, structure and a strong set of rules are other relevant key points to have in mind. Never forgetting that there are human beings behind any nickname or desktop. And never underestimate the power of we.