Tracking dependencies between Agile Teams

March 8, 2017

What do we mean when we say dependencies? 

Probably you already know that a project/product could be developed by many teams and not from one. Actually in most of the cases this is necessary because a small team limited to 9 people max (scrum guide), may not be able to deliver a very large project in a specific timeline.


So what do we do? Of course we scale. We create more teams to work in the project. Most of the times thought, these teams will have dependencies between them. Which means that one team frequently will have to wait things to be implemented from another team in order to proceed with their implementation in some parts.


What options for scaling is out there? 

Scaling is a big topic so we are not going to dive into details. Nevertheless we have to mention some frameworks. The one that comes from is the Nexus framework. Nexus like scrum, is lightweight but, as scrum again, difficult to master. It is focusing on the teams and how to collaborate to achieve potential shippable product in every iteration.

Another well know framework and little bit more heavy is LeSS. LeSS is not only describing how to organize the events and the teams but how the total organization could work together to scale effectively. In the website there are several case studies.


Finally, SAFe is an option but it is considered heavier than the previous ones. 


Implementation dependencies 

Let's take an example to understand dependencies. Actually we will focus on implementation/coding dependencies. Suppose we have two teams. One team is responsible for implementing the statistics of the customer transactions in a bank system.


Also lets assume that we have another team that is responsible to implement the actions that a user is doing via the system/website to her account. Apparently, if these actions are creating transactions then the relevant information for every kind of transaction, that the statistics are interested in, should pass to the statistics component/feature.


Of course the two teams could try to agree on a contract interface of how the data should be, but.. don't forget that the actual integration will show the real status. Working Software is the metric in the Agile world. Apart from that this dependency should be visible somewhere even if it is just for the integration phase.


Visualize the dependencies 

Its very easy to get lost in a big project with many dependencies between teams. Also there are several ways to track them. By using relations between the story ids directly from the tools, excel sheets with various complex matrices and so on.




In any case the important thing is to see fast who is depended to whom and for what. Also the when a team will start the implementation is also important for coordination between team sprints if necessary.


Good visualization make things easier for the important part which is... communication and coordination. Because the details are not important to that phase. You want to be fast in the position to discuss with your peer teams what's going on and who owns what and when they plan to deliver.


Team dependency board 

So here is my preferred way to visualize dependencies.


This can be created easily also with a physical board and stickers. Let's say we have 4 teams. A,B,C and D. The upper part it declares the source of the dependency or in general who we wait for.  That's why is says From.


The left part is the To part and it is the "who gets unblocked" if the item in the cell is delivered from the From team. The grey areas are not valid because the from and the to are the same team.


What is missing.. is the color. This defines the When part. So green means that the team is working in this feature at the current sprint. The blue means that the implementation of that feature is for the next sprint and finally red means that it is planned (or not) for some future sprint.


How far you want to see? 

Well I don't know.. personally I keep these three color because I don't want to get in more details. This board could be used in a cross teams stand up for a quick update. For future planning and coordination you could use numbers to indicate future sprints.




But let's phase it (and remember) that planning in the agile world happens in every sprint based on the results of the previous one.



Please reload

Featured Posts
Please reload

Nikos Raptis -
Agile Coach, Speaker & Developer

I'm a scrum master, speaker and software developer. I love Agile values and principles and...

Contact me

© 2015 Created by Nikos Raptis

  • Google+ - Black Circle
  • Twitter Black Round