1

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?

2
  • "Should I separate the project into 3 parts like AI - BE - Mobile and make 3 tickets with same title ?" - 3 tickets, yes. But probably different titles, specific to their task.
    – Joe Strazzere
    Oct 11, 2022 at 10:27
  • Similar to this: pm.stackexchange.com/a/34366/47877 Oct 12, 2022 at 1:57

2 Answers 2

4

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 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.

1
  • Thanks for your very detailed help Oct 12, 2022 at 4:23
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.

4
  • In the specific context of telemedicine, there may be regulatory requirements to maintain traceability if the software counts as a 'medical device' for which tickets are a mechanism that requires minimal setup. So they may make sense in a specific use case. Oct 11, 2022 at 16:50
  • 1
    @user1937198 No one said you can't use tickets; the point is that you can't let ticketing define the process. I do a lot of work in heavily regulated environments including HIPAA, and there are ways to use tickets for change control and traceability without allowing the ticketing system itself to create steps in the process that contribute to mura, muri, or the consequences of ignoring Little's Law. If you want to ask a more concrete question about how to use ticketing more effectively without violating core agile principles, ask a related question and link back to your original.
    – Todd A. Jacobs
    Oct 11, 2022 at 18:59
  • I doubt I would be able to express a single concrete question rather than a rant on how my organization utterly fails at using things like ISO 13485 as excuses for allowing the ticketing system to define the process and fail at core agile principles and the methodologies they claim to be implementing. Stack exchange is not the venue to try and get into those issues. Oct 11, 2022 at 20:19
  • Potentially there is a question there about an environment that already has reached problematic levels of mura, muri, but again I'm not sure if that is really a question for here. Oct 11, 2022 at 20:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.