In an scaled Agile product-oriented organisation, we talk about dependencies when squads are not autonomous to deliver their roadmap. A dependency is a link between two teams, meaning one team cannot move forward and deliver value to the client without the other having finished their work (example: a front-end development requiring the prior enrichment of an API).

In a vertical organization model, it is common for one squad to need another squad to develop a feature, a technological foundation, or fix a bug before it can put its own functionality into production: this represents a strong dependence. For example, if one squad prioritizes in their backlog the complete redesign of the system for sending emails (with the aim to improve communication with the user), other squads who want to work on “the contact by email” functionality will probably have to wait for the new system to be completed, or help out with development.

This type of dependency is often inevitable: it is corollated with the autonomy left to the teams. A vertical organization will not magically solve the coordination between the teams: it is necessary to ensure that the product remains coherent as a whole and that the collaboration between squads is fluid and not divided. Mediation and dependency management meetings can be implemented, such as PI planning. It is also possible to use visual management or recruit a program manager whose role will be to streamline the organization and support transverse projects. No system is perfect and every organization has to find the drivers and structure that work the best. On the other hand, the more the organization is composed of multidisciplinary profiles and full stacks, the more the dependency management will be simplified.

To delve deeper:

Scaling Your Product Team While Staying Agile: an >hour-long talk in which Dan Podsedly demonstrates the organizational challenges he experienced at Pivotal Software.