Interactions between agile teams in a software company

Question

We try to use Kanban in our development project. Our team is one of many other agile development teams in our company. The other teams may use either Scrum or Kanban or something else (sometimes nothing I suppose).

All teams work on one large project, but this large project is divided into sub-projects and each team works on a sub-project.

There's a pretty much interaction between the teams:

• a team may ask another team to perform a code review of their Pull Request
• a team may come to another team for an expert advice
• a team may request another team to fix a critical bug
• etc

These interactions fall into two groups:

• additional work (decrease our team's velocity and increase context switching)
• blockers (for example, waiting for a code review)

So I'm thinking of ways to effectively manage these interactions. We always have a lot of hight-priority tasks in our own project, as well as the other teams do, so it seems that the managers should come to some common policy about these interactions first.

Have you any experience with such interteam tasks management? How can all this be approached?

Answer 1

There are a few things to think about here.

Firstly, how do you define your priorities? If they are only defined at the individual team level then it makes prioritising requests from other teams challenging.

Ideally where work is shared there needs to be a clear, top-level prioritisation in place so that is easy for teams to know what they should be working on next.

Secondly, look to empower the teams to self-organise. Ceremonies like the scrum-of-scrums can be useful to allow the teams to speak regularly with each other.

Finally, it would be worth thinking about ways to reduce cross-team dependencies. Extra training and knowledge sharing can really help with this. It also helps if you have a consistent codebase, such that it is relatively easy for teams to work on areas of the code that they don't typically operate in. This, combined with good automated regression test coverage can encourage teams to fix their own problems rather than having to rely on other teams to do it for them.

Answer 2

(My experience is with agile frameworks that work in timeboxed sprints. Some of these points won't directly apply if you are following a continuous process framework like kanban.)

The best answer will depend on why these inter-team interactions are occurring.

Here are some possibilities I can imagine:

1. Problem with team composition

An agile team should contain all necessary skills to do their work. Is this true of these teams? If not, why not? Can the composition of the teams be revisited?

2. Problem with project -> sub-project decomposition

Were the subprojects defined with an eye towards making them orthogonal, independent projects that can be worked by independent teams with minimal coordination? Or were they divided on some other basis that is now causing difficulty, and if so, can this be revisited?

3. Problem with team over-committing

Is team A asking for work from team B because they need help to complete what's on their plate within the defined timebox? If so, then the teams need to get better at capacity planning: skills like backlog refinement and estimation.

On a slightly different note, no teams should be planning work to fill 100% of their theoretical capacity. Aiming at ~70% leaves room for developers to do other work that comes along during the timebox: whether that is newly discovered complexity, or surprise bug fixes, or ongoing maintenance, or training... or requests from other teams to share their expertise.

4. Concern about silo-ing

This is probably the best reason I can think of, because it has a good intention even though the implementation is causing problems. If the org's desire is for teams to participate in each other's code reviews & so forth for purposes of knowledge transfer, then perhaps there are less disruptive ways to do this.

A couple of other thoughts:

• If team A knows in advance that they are going to need help from team B to successfully complete a work item in a future sprint, it's a good idea to let team B know about it early enough that it can be included in team B's planning discussions for their relevant sprint.

As a practical matter, I've started sticking labels like "teamb_support" on any such tickets, so that we can easily see and be reminded to make that support request early enough to avoid surprising team b.

• Part of the reason to use relatively short timeboxes for sprints is to make it easier to ask people to wait until the end of the current sprint. "Respect the timebox" typically signifies "don't let things run over it", but it also means "don't push more things into it." Gradually educating everyone in the org to respect the timebox in both senses takes time and the ability to, in fact, defer any requests until the next sprint (which may take support from management and/or the other team leads).

These two points work together: as team A learns that team B is not going to respond to incoming requests in the middle of a sprint, team A also learns what team B's sprint (or other planning) cadence is, and learns to ask in advance.