Silos: visualizing and dealing with the team’s dependencies

Recently, while we were facilitating an EVDnC, one of the teams was having difficulty deciding what tasks should be done by whom, and which of them should be done together. Things like this kept coming up: “But I didn’t know you needed that”, “I was waiting for the Back-end to do it and they didn’t even look at it”, “I’ve some dependencies with you, but I haven’t told you yet”. A lot of discussions and not much alignment.

This was a team with the following specialties: User Experience (UX) and User Interface (UI), Back end, Front end and Quality Assurance (QA). The Kanban board didn’t translate the dependencies and nothing was moving. So we created a different board.

The Board of dependencies

Using a Flipchart sheet, we made a circle for each separate specialty.

Then we drew a line linking each specialty.

We took the user story with the highest priority on the Product Backlog, the one generating the most discussion, and set the following challenge: Everyone list on post-its all the technical tasks each specialist needs to do so that the story fulfills our Definition of Done. Each specialist uses their own post-it color.

The tasks depending on the specialist and only the specialist go inside the circles. All tasks depending on work together with another specialist go on the line. Any task requiring 3 or more specialists should go in the middle of the board.

This Figure shows the board once completed.

Board of dependencies

Board of dependencies


What we can see here is:

  • UX/UI have 2 tasks and don’t depend on anyone;
  • Front end has 6 tasks, 2 depending on UX/UI and 1 depending on Back end;
  • Back end also has 6 tasks, 1 depending on UX/UI;
  • QA has 5 tasks, 1 depending on Back end and 1 all the others.


When the dependency is removed, the task can be moved inside the specialist’s circle.

When the task is concluded, it can be removed from the board. The User Story is ready when the whole board is empty.

Tasks can emerge during development or the team can come across a dependency. Just be careful this doesn’t become an aid to masking rushed or bad planning. New dependencies should always be communicated and agreed upon between parties.


A few agreements are necessary

1 – We should try to resolve the greater dependencies first (center of the board), then the lesser ones (lines) and lastly the specialists’ tasks (inside circles).
2 – Tasks mustn’t be attributed to others. I can indicate a dependency, but I don’t write post-its in colors which are not my specialty.
3 – Agree the best moment for the dependencies to be dealt with. Don’t just wait for the Daily Meeting.

What if there are more specialties on my team?

You can create other board formats (pentagons, hexagons, etc.), but be careful not to have too much team specialty. Remember Brooks’ Law. The quantity of communication interconnections is an explosion of combinations shown in the formula:

Brooks' Law
Brooks’ Law

Bringing it to an image


Brook's Law
Examples of Brooks’ Law

Each specialist node you add to the team adds a communication overhead, increases coordination costs, adds to the complexity of story handoffs and hinders important agile practices like WIP (Work in Progress) limitation and Swarming.


Foto de Avelino Ferreira
Avelino Ferreira

Avelino is a trainer at K21. With a degree in software development, Avelino has undertaken many roles across different organizations: Programmer, Technical Leader, Project Manager, Scrum Master, Product Owner, and Manager.


Leave a Reply

Your email address will not be published. Required fields are marked *

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Please notice that we do not keep any personal information though.