Organizing Ongoing Software Product Delivery With In-House And Outsourced Development Teams

The best way to carry out a software project is to hand it to one team who will be solely responsible for the ongoing cycle of product development and delivery. However, modern businesses are rarely limited to a single product. Established companies and enterprises tend to outsource software development of new products, already having in-house teams to handle their internal ecosystems. For such cases, organizing effective collaboration processes is the key.There are three common cases when two different development teams collaborate on your software project:• Case #1: You have an in-house development team that handles your existing ecosystem, and now you need to kickstart development of a mobile app. That's a usual thing for established companies with their own infrastructure and security measures. When you invite a new mobile development team, they must get acquainted with your company and align with your processes and goals as quickly as possible.• Case #2: You have one remote team that handles your ecosystem, and now you have the need to promptly augment it with another remote team. This is typically the most complex and problematic situation, challenged only by the case of a distributed team working on the same product.• Case #3: You are a developer and you handle a part of the whole job, while a remote team takes over the remainder. This is actually the least problematic case as there are only two parties involved. You can contact your team members directly, give tasks and check them yourself, having full access to issue trackers and documentation.Whatever your case is, you want to avoid poor communication, delivery delays, and your personal dissatisfaction with the process.How do you start building effective collaboration?First of all, the collaboration between two different teams often revolves around API, which connects a new product with your entire system. It's crucial to define the principles of collaboration. Software developers and managers from each team have to gather together and see what kind of API is needed and how it's supposed to work. An official API specification should be made with all the details, data formats, functions, examples, and delivery dates for effective planning of further work.Everyone must hold on to the approved specification. The work begins with test data, and the team works with regularly updated documentation. Discussions and reminders are easy to set up when everyone is in the same office. However, a number of available tools for remote communication and collaboration make life easier. If every important call is attended by managers and tech experts representing each party, it's the best way.What are the possible problems?Software projects rarely run without communication problems. There are time zone differences, language and mindset barriers, collisions of opinions and responsibilities, and the omnipresent "it's not our problem" factor that appears between teams. As a result, there is idle time in waiting for answers, additional expenses, API delivery delays or improper APIs—and more distractions for you. These problems can have negative impact on the product. However, if you know them, you can prevent them effectively. Let's make a brief return to our main cases:What are the possible solutions?#1. Choose your approach to the interaction between your teams—and document their responsibilities. Approach #1 says, "One team is always right." It's the 'totalitarian' one; but in fact it is very clear and effective. One team takes the lead—together with the responsibility, of course. Approach #2 says, "Both teams have equal rights." This one is 'democratic'; your teams can discuss and offer tech solutions, while you have the final say. That's not to say that this approach is bad: if everyone is open to solving problems, they will be solved.#2. Direct developer-to-developer calls to solve urgent issues, which don't require your involvement. In many cases managers from both sides will do just fine.#3. What if your in-house team provides an improper API – a web service that does not follow the specification and causes problems within the app? There are two ways to solve this commonplace issue:For approach #1: the remote team works with whatever they receive from the other team, and suggests a proxy API that will adjust formats so that everything will work properly on your app without harming its performance. It takes a little more time, though, but it's a solution that works.For approach #2: the best way is if your in-house development team takes a little more time, corrects everything and sends us a proper API as requested. Again, it will take time, but the result will be optimal for your software.#4. If your in-house team fails to meet delivery dates for some reason, the risk is not carried by the remote team—they cannot actually solve this problem. Thus it's reasonable for you to set the priorities of your in-house team beforehand to prevent such situations.#5. Sometimes delivery dates are failed for good reason. For example, when there's a conflict of priorities: your core system requires tweaks, and your in-house team is busy tackling them, while your mobile app is of lower importance. Of course, you are notified, and the remote team proceeds to other tasks on the agenda.#6. The time has come for the real ace of a solution: your visit to the office of your remote team. It tends to last just a couple of days, up to a week usually. However, it leaves a huge positive impact on the project. Such visits are cheap investments that pay off in the long term. They break communication barriers, build trust, and start friendly and productive business relationships. The same goes for return visits to your office. It's easy to get acquainted with your team members personally. And it solves problems like nothing else.