Relying on knowledge of external teams

Last post 01:02 am October 31, 2019
by Season Hughes
3 replies
05:20 pm October 30, 2019

In our last Retro, I had each team member choose at random a pain point identified by the team to help solve as their action item for the Sprint.

Mine was "relying on external teams' knowledge."

What this looks like in practice is we're building technology that is used by other teams, or we are building upon technology previously built by other teams. So our team often has questions for other teams about the history of a build, or they might need to consult with other teams when something goes wrong, or they give another team a heads up that what we're working on may affect the other teams' work.

This can slow our work down, especially when the external teams are in other time zones. And I also suspect feelings are creeping into this - our tech lead is very sensitive to the team going outside for information, takes it as something lacking in himself, and wants to be the main source of knowledge.

But, for the overall team, I'm stuck on how to help solve this. I had some ideas:

- invite the other teams to our standups and reviews (time zones don't overlap, though we do record our reviews)

- attend other teams standups or reviews (time zones)

- invite an external team member to share at a standing bi-weekly knowledge share the team has (I was told the external team member we rely on the most wouldn't be comfortable sharing)

- pair programming with other team members (would be similar to above - time zones and discomfort)

- document what we learn from other teams so we can refer back to it (team is already doing this in Confluence and Jira)

- work on coaching the team lead and his feelings

I think the idea I'm most interested in at this point is:

- be OK with it. This is a natural part of work.

Have you had any success minimizing reliance on other teams' knowledge? Or coaching a team to accept this as part of work and optimize their work and comfort around it?


05:27 pm October 30, 2019

Is there any avenues on this list that the team is interested in pursuing? For example, documenting learning from external teams could help this team not have to rely so heavily on others in the future as they learn the applications. 

I've seen paired programming or peer code reviews work really well for teams assuming the external teams are willing (and have the time) to participate. 

My thought is to think long term (even past the current team's tenure) on how to obtain and keep the domain knowledge to reduce these dependencies over time. This could come in the form of cleaning up code, documentation, pair programming, and so on. 

06:49 pm October 30, 2019

Mine was "relying on external teams' knowledge."

At which point do they rely on it? During Product Backlog refinement? If it’s later than that, why?

01:02 am October 31, 2019

Tony, great callout on thinking long term. I will keep that in mind.

Ian, they rely on it while they're working. They'll be working on a story and then not know how to proceed because they don't have context or history, so they ask outside the team.