How to organize cross-team work in the METEOR task tracker

Today we will share how to organize inter-team work in a tracker, what difficulties are associated with this, and what are the ways to organize such interaction.

Why is inter-team work needed at all? At a certain stage of company development, a fairly clear team structure appears. Very often the workload in teams is not the same. In these cases, many resort to collaboration between different teams on the same project. This is where everything that we describe with the term begins inter-team collaboration.

It's important to note. If you use a tracker without roles and rights, or if your users from different teams see each other’s tasks and can work with them and you are happy with this, then this article is not for you.

The article will be useful to those who differentiate access rights by team, project and are faced with issues of correctly organizing the collaboration of different teams with each other.

There are three main ways to implement cross-team work:

1. Temporarily adding users from different teams to teams with which there is interaction.

2. Create a shared collaborative project and add collaborating users from different teams to that project.

3. Transferring tasks from project to project.

Let's look at all the advantages and disadvantages of each of the described approaches.

1. Temporarily adding users to each other's teams

In this method, you need to add users of one team to another and vice versa – cross-add. This method cannot be implemented in all trackers. The important thing here is that the tracker supports adding users to multiple projects. METEOR supports adding users to different projects, specifying the specific roles with which the user will work with the project.

Why do we focus on the word “Temporary” in this method? This method is the fastest. It can actually immediately provide all the necessary interaction tools.

But this method also has significant disadvantages:

1. The principle of “the only relationship between the user and the team” is violated. Those. For such users, it becomes very difficult to get an answer to the question: “Which specific team does this user belong to.” The consequence is a violation of reporting and regulatory procedures (for example, calculation of team bonuses). Additional adjustment of accounting tools may be required so that the statistics do not float.

2. This method allows a user from another team to see and participate in tasks that are not cross-team interactions. This may lead to accounting errors (for example, users from other teams will be mistakenly selected as performers in local team tasks). And also, in general, the isolation of the team’s list of tasks is disrupted.

3. An even bigger disadvantage is that you need to remember that after inter-team communication is completed, you need to remove users from “other people’s” teams.

So, to summarize:

Pros:

• Interaction launch speed;

• Few restrictions for interacting users.

Minuses:

• There is no understanding of which team such users belong to;

• Unnecessary access to tasks not related to interaction;

• Administration is required both at the start of such interaction and upon completion.

2. Creating a joint project

This method is much better in all respects compared to the previous one. This can be depicted in a diagram like this:

In this method, the “Project” analytical view automatically appears to track such interaction in statistics and reporting. You will always have information about which projects a team member was distracted by and to what extent.

The second great advantage is the complete isolation of such interaction from a host of internal tasks. There are no changes to your team's home project that could lead to security breaches or errors.

Projects created for such interaction can be marked in a special way so that they do not destroy your statistics and regulations, but rather provide useful data about such interactions. Projects can be tagged in different ways depending on the capabilities of the tracker. In our METEOR you can place projects in a single hierarchy or set custom field values ​​for filtering.

We also consider it important that this method does not require “cleaning up” after the end of the interaction.

So, the pros and cons:

Pros:

• There are always analytics and statistics on interaction;

• The access control system to command spaces is not destroyed;

• No “cleaning up” required upon completion;

• Few restrictions for interacting users.

Minuses:

3. Transferring tasks from project to project

We consider this method an alternative to the previous one. It has a number of advantages, but, unfortunately, also disadvantages. It might look like this:

Let's first look at the pros of this approach:

In cases where a task, during its life cycle, is born in one team and completed in another, this method will be the easiest to implement. It does not require setting up rights and roles or creating additional entities. You can easily track all performance indicators by team/project.

The second undoubted advantage is the naturalness of this process. Let's look at an example: I received a request to the support team. Support qualified this request, made a technical description, determined the route for this task and transferred it to a specific team. It's very simple and clear.

One of the disadvantages is that not all trackers support changing teams/projects in a task.

The second disadvantage is that if a task can “travel” across different teams and even return to the one where it was created, it becomes much more difficult to collect analytics on such interactions, search for bottlenecks, and synchronize across service levels.

As a result, it can be noted that in a number of specific scenarios this approach is good, but in others it may be inappropriate.

The conclusions are:

Pros:

• Simplicity and naivety of the “process”;

• Analytics and statistics do not suffer;

• No complex setup required;

• Very well suited for tasks that are not returned to teams (support, administration, marketing).

Minuses:

• Tracker support required;

• Not suitable for “constantly traveling tasks”, for example, interaction between architects and developers if they are members of different teams.

The examples we gave in this article are taken from life. Of course, companies are different and the level of process maturity in them also differs. But the “average temperature in the hospital” is approximately this.

If you have other ideas for organizing cross-team work, please share them in the comments.

Thank you for your attention! We wish you simple, high-quality, transparent accounting and high efficiency. Spend more time creating!