If you worked in large organizations you have probably heard about the term “dependencies”. I am convinced that dependencies need to be eliminated, not managed. With a help of system diagrams in this article, I will uncover the main reasons why Scrum Teams suffer from dependencies, how they impact organizational agility, and what the fundamental solutions to this issue are.
The more dependencies, the less chances the feature will be done by the end of the Sprint. Thus, the more time it takes for the feature on average to go from Product Backlog queue to the market (cycle time). As a result, agility is reduced because the organization is unable to deliver potential value to the market quickly. This causes organizational stress.
A typical management response to organizational stress is “divide and conquer”. For instance, if there is a problem with the quality, let’s create a separate department “quality control” with set of its own KPIs. Creating new functions, units, component teams and coordination roles, managers strengthen the fragmentation of the organization. More fragmentation leads to even more dependencies.
High average cycle time makes the organization less agile. But Scrum Teams should not have any dependencies!
Cross-functional teams have all competencies needed to accomplish work independently from ones not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. – Scrum Guide 2017
Basing on my long experience working with large organizations I see some reasons why the dependencies thrive:
The dependencies issue could be solved in two ways: with quick fixes or fundamental long-term solutions.
The quick fix is to visualize and manage the dependencies. E.g. creating additional coordination roles or using specific techniques (“ropes on the boards”). Yes, it somehow helps to survive and continue the movement. You become an artist of the visualization and dependency management. Your work looks like this:
The fundamental solution is to completely eliminate the root of the problem by:
In this case the board for the scaled Scrum could look much better (no dependencies):
Feature Teams do not need the strings because there are no dependencies or they are trivial.
Let’s get back to the system diagramming. On one hand, we have a cycle explaining the rise of dependencies, on the other hand it is a quick fix of the problem, then a fundamental solution cycle and the final cycle of forming a culture of managing dependencies when time passes.
The bad news is that a strong culture of “managing dependencies” will hinder the implementation of the fundamental solutions.
Do you manage dependences or want to eliminate them?