Should we use different project trackers for different teams working on the same product?

Question

We have been using a popular project tool, Pivotal Tracker. We have decided to break up our product team into 3 separate teams, each focusing on features with a particular theme. There is some debate about whether each team should have its own tracker, or whether we should use one integrated tracker.

The teams will stay together for at least a quarter of the year. It is all going into one codebase and in one source repository. We share demo and staging environments as well. We are also all in the same room.

Any advice in either direction? My inclination is to keep it all in one tracker and use labels to differentiate, but I wonder if it's useful to have separate velocity calculations for each time. Any thoughts would be welcomed.

Answer 1

My inclination matches yours; I can't think of a situation from my own experience in which I would create separate trackers for the same project but for different teams except a situation in which the calculations or reports you are trying to produce cannot be done at the tag or component level, or in any other easily-determined-per-team way. It seems to me that focusing your tools on the construction of the team would be more about managing the different teams than managing the project itself.

Answer 2

If the teams are working on different parts of the project that can be considered as autonomous sub-projects that together form a larger project then consider the division.

From your description is sounds more like one big team working on the same project divided by areas of expertise for the sake of conformity and interchangeability between the developers within each sub-team.

Answer 3

Integration takes time and costs money. It'll require effort, and money, to keep each project synced in a single tool. If these teams will have a lot of back and forth, dependencies, and coordination, this would be money well spent. If the team if simply off on their own and they will deliver their piece of the pie when they are finished, then I would question the cost of integration. Intuitively to me, it seems more logical and simpler to use one tracking tool. But we do not improve if we do not challenge the status quo. If there is debate on the team, then a few members are seeing a benefit there that should be examined.

So, the first I would look at is cost. Second would be integration and how easy it would be for me to really know the status and health of the teams and the overall project. Would it be better for me to mistrust one tool, or three?

Answer 4

If the 3 teams were all working on completely separate projects, I would be tempted to treat them as 3 separate entities and 3 separate experiments. When you give small teams the freedom to operate independently, it frees them up to experiment and find methodologies that help make them the most successful.

If one team makes a discovery that fires their productivity into the stratosphere, the other teams may decide to adopt it and vice-versa.

However, in this situation, there is a very strong likelihood that the 3 teams will need to work closely together. After all, they're all building the same product. If you set the precedent that it's okay to diverge from the group and use different tools, then it may be difficult to merge the teams later on, and it may be difficult to create cross-functional teams during integration periods.

In this situation, if at all possible, my suggestion would be to pick a single system, and stick with it.

Answer 5

In addition to the above, if you break it into a few systems, there is a risk that you will lose good visibility of your product's state and progress.