Imagine two teams, A and B, both working on the same piece of software. How do you solve the problem arising from team A having a work item X which they cannot implement because it requires something that team B are working on to be done first?

Whenever a dependency is obstructing progress, you probably have a missing or leaky abstraction.

Take a step back and consider the boundaries of what you are trying to achieve. Team A shouldn't really care how team B solves X. So let them pretend that it has been solved! The accept criteria for their task should be independent of team B's efforts anyways; the tests that team A come up with for their task should be executed in isolation - in other words under the assumption that everything else works. I've written about this at a lower level before - the same principle of dependency inversion applies here.

Of course, later when both team A and team B are done, they merge their work into an integration branch where integration testing etc happens.