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.
How dependences inhibit Teams progress
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 the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
Scrum Guide 2017
Why dependencies exist
From my long experience working with large organizations I see a few reasons why the dependences thrive:
-
Imperfect organizational design based on component teams ( "bus team", "analytics team", "Android Team", “integration team”). It causes intensive fragmentation.
-
Incomplete cross-functionality (lack of one or more skills).
-
Unreasonable complicated architectural design ( f.e. "there are 256 systems in our organization"), which inhibits creation of cross-component and cross-functional Scrum Teams.
How to get rid of dependences
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 similar to this:
The fundamental solution is to eliminate the fundamental issues completely by:
-
training people
-
making the complicated architecture simpler, reducing the number of components
-
changing organizational design and forming cross-component cross-functional Scrum Teams (Feature Teams)
In this case the board for the scaled Scrum could look much better (no dependencies):
Feature Teams do not need the ropes 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.
Key Ideas:
-
The more dependencies the less agile organization becomes.
-
Dependencies thrive because of the unnecessarily complex architecture, lack of skills, and suboptimal organizational design (component teams).
-
Creating additional roles and using dependencies management practices do not eliminate the fundamental issues.
-
Fundamental solutions are simplification of the architecture, Feature Teams and, training people.
Do you manage dependences or want to eliminate them?
Scrum ON!