Eliminate dependencies, don’t manage them

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.

why_dependencies_thrive

Key Ideas:

  1. The more dependencies the less agile organization becomes.
  2. Dependencies thrive because of the unnecessarily complex architecture, lack of skills, and suboptimal organizational design (component teams).
  3. Creating additional roles and using dependencies management practices do not eliminate the fundamental issues.
  4. Fundamental solutions are simplification of the architecture, Feature Teams and, training people.

Do you manage dependences or want to eliminate them?

Scrum ON!

转:https://www.scrum.org/resources/blog/eliminate-dependencies-dont-manage-them

更多文章

业务架构学习群资料

W3.3 政策

政策地图是业务架构的一个很少引起关注的方面,但至关重要。政策影响战略、能力和价值流、信息、举措、业务单元和合作伙伴,随着业务生态系统映射到多个业务和业务模型,政策地图的价值也将增长。

阅读更多»
星球资料

客户体验度量和KPI

客户体验是一个复杂的实践领域,需要清晰的愿景、正确的工具和出色的执行力才能成功。建议从三个主要方面来考虑CX:获取(A)、留存(R)和效率(E)。我们把这三个区域称为CX值方程:CX=A+R+E。A指组织增加客户群的能力;R是组织保持和发展现有客户的能力;以及E允许组织用更少的资源做更多的事情。

阅读更多»