There is a common rule in parallel computing — if you want to compute something two times faster, you have to use three times more powerful hardware. However, this rule works differently when applied to software development. Let us see how several teams can work in parallel and what are the best practices.

Why Do We Need That?

First of all, parallel development may significantly speed up the development process and deliver the product earlier. Remember that it is valid only if all teams work together, all workflows work perfectly, and there are no major communication issues.

Another related advantage is the resource savings — time, human resources, and financial capital. It is clear for time-based resources but may look counterintuitive for financial resources. You need to understand why the project has to be done early. It is usually necessary to acquire a competitive advantage, develop the company, and become more profitable in the long run.

Finally, parallel development may help to utilize human resources fully. For example, if some team has some spare time between projects (let us say several months), it can be brought to another project to implement several features. Just pay attention that introducing and picking up speed will take some time, so you need to take it into account.

Unexpected Consequences

We are not going to discuss typical well-known issues described in The Mythical Man-Month. Every software developer who has ever worked in a medium or big team already knows it by heart. Let us check less obvious consequences and issues.

If the project has several teams working in parallel, somebody needs to plan work for all of them — this is obvious. However, this person also needs to schedule the time for internal calls and discussions, resolving technical conflicts, and make sure that all teams, in the end, will produce a solid product, not lots of small pieces that can not work together.

The application architecture must be flexible to ensure the parallel development of different features or components without significant conflicts. It is impossible to eliminate them as almost all features have dependencies on other features. However, if the architecture allows building 90% of the functionality without conflicts, it is good enough to be used for parallel development.

When a project has only one team working on it and this team makes a mistake, only one team is blocked, and the highest priority is to fix the mistake. However, if you have many teams, one team's mistake can stop all other teams. There are two best practices to deal with this situation. First — solve blockers as soon as possible. Second — always prepare secondary tasks, so the blocked team can take them until the blocker is resolved.

Finally, there is a human factor. The more people involved in the process, the higher probability of communication issues, interpersonal conflicts, and other "soft" issues. Every team member must be prepared for these issues and try to maintain a friendly atmosphere and healthy communication between teams.

Do It Right

When the project requires parallel development, the project manager has to plan the risks. They may include unexpected technical conflicts, additional sessions of refactoring, and, consequently, significant delays.

Higher risks may lead to higher expenses that have to be planned too. The best practice here is to track the number of found and fixed issues and then try to predict and plan extra time for future issues.

Please remember that parallel development may work only if all participants have enough experience. Project managers, architects, developers, QA engineers — all team members should know how to work in parallel using the multi-team approach.

In some cases, the parallel development may not be with it. For example, if the project is not that big and the teams do not have enough experience, it may be easier, faster, and cheaper to implement the project using only one team.

Here are the standard recommendations and best practices for the organization of parallel development. You may use these recommendations as they are or adapt them to the specific use case. Just remember that parallel work requires more effort and more attention by its nature, and it should be taken into account from the very beginning.