I’ve been thinking for a while now about how to visualise and manage (reduce) the dependencies between teams. I was watching a presentation the other day where the speaker was using “markers” to see the current position of certain work items in the flow (in a completely unrelated presentation), and I started to think what if we used the “marker concept” to see where a work item done by a specific team ends up? If we can find markers from another team on a team’s board, it means that the second team depends on the first team. Thanks to the markers the dependency is immediately visible and thanks to the inventories it is manageable, too. Fantastic.
The whole concept is actually quite simple: let the teams have specific colours (these colours must be different from the colours the teams are using on their boards) and mark the done work items and the work items representing their requests towards other teams with this colour (mind the bluish color on the second board, the board of team 2):
If another team picks up a work item from that team, or gets a request, they put it on their board, and the dependency between the two teams is immediately visible. Of course, if that done work item or request has to move to another team, the work item shall have two colours: the colour of the first team and the colour of the second team (but don’t create a mixed colour with PhotoShop because there is no way that humans will be able to figure out the original colours). This way we can see indirect dependencies, which is actually worse than the direct one because the third team thinks that it depends only on the second team, but actually it depends on both the first and the second teams.
If the “received” work items are visible, we can manage them, and the best way so far is to have an inventory or queue for them and put a limit on it.
If the team already has a backlog-like queue (Q on the boards above), the dependency queue must be put before that. At first this may look like an overhead, but remember that we have to make the dependencies visible and manage them. So, if there is a queue and it is full, the team can tell the other team that they cannot take anything more from the other team unless they give something back to the other team. Another alternative can be a CONWIP system where the overall number of dependent work items are limited. In other words: if the second team has a CONWIP of 2 on the dependent work items and there are 2 ongoing ones, the team cannot pull in another one until it finishes at least one of the ongoing ones.
We can even create a nice chart to visualise how the queues of dependencies change over time:
Team 3 is less dependent on team 1 after a couple of weeks, but it is still heavily dependent on team 2 and that is not good.
comments powered by Disqus