Dependencies of teams in Agile
How to deal with inter-team dependencies? It is not easy to answer the question. The differences might be of different types and therefore the solution of such dependencies will be different.
In Agile we try, as a principle, to limit dependencies by the restructuring of products, change of architecture, and sometimes even with a change of technologies and company structure/organization chart. We want to achieve the capability to deliver end-end value for customers and organize teams necessary for its development into groups supporting some value stream.
Dependency in the value stream is natural and can be easier to manage. Such teams should be not built based on the technology layer (for example database, backend, front-end team) but rather on the product/system part. End to end. One such example is Spotify company there can be a team for a player, playlist management, data analysis, etc.
Teams in value stream follow these additional principles for easier synchronization:
- Work is planned ahead not just for one sprint but in release (program increment) cycles.
- Work is visualized with help of program boards.
- Problems are broken into more details by aligned product owners.
- Teams help to identify dependencies and risks not later than in release planning and sprint preplanning sessions.
- Once the work has been done by the team, Scrum Masters inform other depending teams about the status in Scrum of Scrum events.
- ScrumMasters meet daily to synchronize inter-team dependencies.
- Teams should incorporate “We are vendors, we support customers whoever is it” way of thinking. Anybody outside of the team is our customer we should support and help to be successful. It doesn’t matter that he is a colleague we meet in the kitchen.
- Blockers have to be visible and solved as soon as possible. Management should collaborate with Scrum Masters on that.
Program Board example
If it is not possible to change the structure of the company, try to build virtual agile teams at least.
