Interactions between agile teams in a software company

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

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

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2