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