Separation of multi-team project into several projects

Question

When should a multi-team project be split to run as separate projects? Where lays the border, when something should be run as separate project?

Case:

• 3 feature teams (DEVs+QAs) working on product backlog items (features, bug fixes), and use automated acceptance tests package at
  a final stage of feature verification.
• 1 AQA team, who create automated acceptance tests packages (mentioned before) to test the product from client perspective. This
  package is delivered to the client and to feature teams.

Currently this is run as one project, but maybe it is better to split them into 2?

I came up with the following possible criteria for separation:

1. Different release cycles and periods
2. Different life time
3. Different workflows and definition of done
4. Possibility to identify clear independent (from other teams) deliverables

Are there any other criteria to consider or maybe mine are redundant?

Answer 1

TL;DR

In most cases, you should only have one project per product. The desire to split a single product into multiple projects is usually a sign that inter-team collaboration and iterative integration have become a central bottleneck for your process. I provide additional analysis and recommendations below.

One Product ➡️ One Project ➡️ One Integrated Increment

When should a multi-team project be split to run as separate projects?

As a rule of thumb, each project should run from a single Product Backlog. In each of your examples, you may have multiple teams, but each team is still fundamentally working on the same product.

Even if you’re split into feature or component teams, you’re all still developing the same product, and should all be working from the same top-level Product Backlog. You want to keep this central coherence, as it’s a core element of cross-team collaboration.

Your actual challenge seems to be integration. When working with multiple teams, or when work is split along feature or component lines, the central challenge is to ensure that the loosely-coupled work that each team is working on during the iteration still comes back together to represent a potentially-shippable increment at the end of each iteration. That potentially-shippabke increment is the central coherence that aligns your teams and keeps the product development on track.

Scaled frameworks like Nexus or SAFe each approach this challenge differently, but they also share some commonalities. Continuous integration is a great practice if you can manage it, but that’s not always practical at significant scale. However, frameworks like Nexus address the need for cross-team integration by having a dedicated team whose responsibility is to ensure that all work from the various teams can be successfully integrated and delivered as a unit at the end of each iteration. Whatever framework you follow, ensure your teams are collaborating sufficiently to allow for continuous or per-iteration integration, so that the product is always in a potentially releasable state at each major inspect-and-adapt inflection point.

The details may vary by framework or by organization. However, unless you are actually attempting to deliver multiple products, you should ensure that your teams maintain a central coherence and treat iterative integration as a first-class element of the multi-team process.

Answer 2

Generally, the question I would ask is: "What benefit do you gain from splitting them?" The risk in splitting them is that your prioritization loses focus on end value and, more broadly, that you could get a lot done, but not meet the success criteria of the project because some teams excel while others struggle and you erode focus on that.

Many times I hear this, the stated benefit is so that one team doesn't slow down another or that reports look better, which aren't real benefits. The reports are superficial and if you really are doing a multi team project, the teams are still dependent on each other, splitting the projects just makes the impact less obvious.

So generally speaking, if it is one project because that is what matters to the customer, don't split it unless you can make some strong case for extra value to the customer that they can't get without the split.

Answer 3

First, a multi teams project is having many teams working in the development or sell of one project. Your question is how to reorganize a company or a department in many projects. So, you have employees that can be asked to change their daily work. They will have to work for another product development or sell.

Second, it is the boss who decides. The profitability of a business resides in the ability of the boss to offer products that his or her clients will buy on a long term period. A good business man or a good business woman, will regularly adapt the products of the company to assure steady cash flows that can cover all the expenses of the company that accumulate each month.

Third, it is not the same thing if you are a public company or a military owned company. They are more bureaucratic and they do not have the same pressure of assuring monthly revenues because the money comes from the government, from the taxes everybody pays. Most of the time, the government shut down public companies that cost more than what they bring.

Fourth, don't leave to your employees a choice. Put the best qualified persons at the best place for you to reach your goals. Many employees do alliances with other employees to assure a long term career; but the perspective of the employer is not at all in that direction. If some see a job like a reward or a way to have a good life for a long time, they can be surprised if they are asked to move to another department or if they are fired.

Finally, regularly remind to your employees that if you don't have sufficient revenues, you will have to close your doors and that everybody will lose their job. It is more important to focus on the development of products to assure a steady profitability of your business than on the career of your employees. A companies that have many products will succeed longer than a company who focus only on one. Be sure that the products you choose will sell.