How can I effectively manage a ticket which needs developers from multiple teams?

Question

I'm a new project coordinator.

My company is developing a telemedicine - AI mobile software. We have the AI team, the Back-end team (as BE) and the front-end team (we call them Mobile). So each time we try to develop new features or fix bugs, we need to create new tickets, and most of the time there are 3 developers from 3 teams involved.

We are using dev.azure to manage all the backlogs; normally, it can only assign the ticket to 1 developer at a time. Sometimes the ticket can be finished step by step so we have a sequence such as BE→AI→Mobile. It means when one team has finished their job, they can assign the ticket to the next. But when the developers can do their parts simultaneously, it's hard to manage them.

So my question is what should I do in this situation? Should I separate the project into 3 parts like AI - BE - Mobile and make 3 tickets with same title?

Answer 1

The solution to the problem isn't changing how you use the tool. The problem arises from a problem in how the work and team is organized.

The option that is most consistent with agile methods like Scrum (and this question has the scrum tag) would be to form a cross-functional team. A cross-functional team is a team that has all the necessary skills to complete the work and deliver the product. Instead of involving 3 people from 3 teams, you would involve at most 3 people from 1 team.

Because you have a cross-functional team, you can develop cross-functional team members. Techniques like pair and mob programming can allow people with different skills to take on a problem together, while also sharing their knowledge. Because you have a single team, it also becomes easier to plan training and knowledge transfer sessions. Although some skills are difficult to master, you could develop enough knowledge that individuals can complete work with less hands-on effort from others.

Having a cross-functional team is also more consistent with lean principles. Hand-offs are one form of waste. When you have hand-offs of work, you also need to have hand-offs of knowledge. That usually means either producing written documentation or facing interruptions when doing other work with questions. It also increases opportunities for rework.

If you are unable to form a cross-functional team, you would need to look at adding more planning and dependency management. This approach would hamper the ability to use Scrum as it's defined in the Scrum Guide. You would need to shift away from adaptive planning techniques toward more plan-driven and predictable approach, which are often less suitable for software development endeavors.

Answer 2

TL;DR

You're allowing your ticketing tool to drive your process, rather than using a set of tool to support a functional and well-defined process that already works smoothly. Don't do that!

Agile Frameworks Require Self-Managing Teams, Not Tickets

You're trying to force a workflow based on ticket assignment onto an agile process. It works poorly. Absolutely no one who understands Scrum or Lean principles would find this outcome surprising.

If you must use ticketing (which I refuse to accept a priori) then tickets should be pulled by teams rather than assigned to people. Scrum and Kanban in particular are pull queues; work is pulled from one activity to another as work-in-progress limits permit. They are never pushed or assigned from on person to another.

Adapt your tool to the real workflow, or toss the tool and find one that supports your workflow. Doing anything else is asking for trouble.

Why Have Three Teams?

If you have 7-9 people spread across three "teams," they should really be a single cross-functional team. If you have 7-9 people per team, then Scrum is not a good fit by itself. You should be looking at a scaled agile implementation such as Nexus, which provides a fourth integration team for each collective Increment.

You should also not be defining and assigning tickets to teams or people. Scrum requires self-managing teams, so each team need to understand the Increment being built, have a cohesive Sprint Goal, and a clear Definition of Done. The Product Owner should define what needs to be built, and leave it to the teams or team members to determine how best to build it.

A lot of your question would resolve itself if you let the team members determine how and where they need to integrate with one another. This won't happen on day one; you need to give the process time to evolve, so that the team(s) can learn how to work together in the most efficient way possible.

Collaboration and Test-First Development

The fact that you think of front-end, back-end, and AI work as distinct is a problem, too. Unless you have a solid Definition of Done and executable tests at the beginning of the work before a single line of code is written, how will anyone know if they've built the right thing? Instead, the consolidated team or multiple teams need to work together to define what should be built, how they will know it's been built right, and collaborate from the very beginning of the iteration to ensure that they are all working towards the same objective for the iteration. In Scrum, this is the Sprint Goal.

Tossing stuff over the wall to one another is not the way to make this happen. Instead, the team or teams should be working together from the beginning. For example, if the front-end team needs to have an API endpoint to get data from the back end, and the back end needs some bit of AI code to return the correct result through the API, then these are not distinct tasks. They represent a single Increment that needs to be coordinated across three closely-related skills sets and activities, and that requires active collaboration.

If you're going to have specialists, they need to collaborate and coordinate. You can't simply have them work independently and expect the edges of what three separate teams are building to join together smoothly. Build in a collaborative process and a swarming mindset from the beginning, and you'll find the work flows a lot smoother.