1

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?

  • 2
    Are these teams working all working on the same product or are there multiple products and some instances of cross-team interaction simply a matter of knowledge and expertise? – Thomas Owens Jan 19 at 20:32
  • 1
    Why are teams trying to track internal state for externalities? Either you have a shared project or you don’t. Instead of focusing on framework specific solutions, you may want to describe the real business or political problem you’re ultimately trying to solve for. – Todd A. Jacobs Jan 19 at 23:30
  • All teams work on one large project, but this large project is divided into sub-projects and each team works on a sub-project. – Chris Brettini Jan 20 at 4:22
  • Who is responsible for integration between work-streams, features, and deliverables in your project? – Todd A. Jacobs Feb 19 at 13:42
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.

  • A "consistent code base" will "encourage teams to fix their own problems"? In a setup where teams are used to ask other teams to "fix bugs"? They're simply going to change the code for that corner case where the behavior hasn't been specified? – loom with a crew Jan 21 at 3:57
  • That is definitely a danger and highlights why the teams need to be talking together frequently. For example, I would hope that somebody about to fix a bug in some code they don't usually work on would go and have a chat with somebody who was more familiar with it first. Chapters and communities of practice should also help. – Barnaby Golden Jan 21 at 8:18
  • I've seen a business logic spread across layers due to an ugly design flaw (unfortunate and unnecessary assumption), other developers come across one part of it and feel that it's wrong, study the multi-threaded and asynchronous behaviour, and change the code to the worse. And in the end, the root cause appears a single technical debt item, somewhat misleading the occasional audience about its severity. Talking didn't help much here. – loom with a crew Jan 21 at 20:53
  • @loomwithacrew, the talking should have had the effect that the unwary developers became aware of the design flaw and that they should proceed with extreme caution. – Bart van Ingen Schenau Feb 19 at 15:38
1

(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?

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

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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