Seven Lessons About Dependency Management

What are the lessons we can learn from my recent article, Tyranny of the Timebox Revisited, and the release of our infographics for Triage Tables and Dependency Management? Why  is it that organizations using Agile methods such as Scrum  and SAFe struggle with and suffer anxiety over dependency management,  while it is largely a non-issue for organizations using the Kanban  Method?

1. At scale, dependencies are a fact of life; you cannot design them out

Beyond a trivial scale of a single team, organizational design, or  even product architecture and design, approaches to eliminate  dependencies are ineffective. Any attempt to design out dependencies  tends to design in mediocrity. Dependencies for large-scale  organizations and large-scale products or services, or products that  aspire to be market leaders, are a fact of life. Instead of trying to  eliminate dependencies, we need to learn to manage them elegantly and  effectively.

2. Upfront dependency discovery, planning and management is expensive

To determine whether or not dependencies in work exist can take a lot  of time and require advanced analysis, design and product architecture  skills. To acquire the information needed to adequately manage  dependencies ties up our best people in speculative upstream activities  and is likely to disrupt and delay delivery of valuable committed  work. The time commitment and the number of people involved are often  punitive. In a worst-case scenario, we heard about a German automotive  manufacturer that rents a sports arena and brings 900-1500 people to a  3-5 day meeting in order to plan 3 months of work ahead. We believe that  as much as 85% of this cost overhead and disruption is avoidable  through a proper understanding of the impact of delay on the deliverable  work.

3. Batch and scope control using time constraints such as sprints, in Scrum & SAFe exacerbate dependency management problems

If work committed to a customer has to be delivered within a 2-week  time window, then it becomes critical to know whether or not that work  might be delayed by a dependency.
If work committed to a customer has  to be delivered within a 2-week time window, and that work might be  too large for a single team to complete in the given time, then it needs  to be analyzed and broken down into smaller pieces. This creates  additional dependency management overhead. The use of timebox  constraints to limit batch size causes peer-to-peer and parent-child  dependency management problems.

4. Peer-to-peer & Parent-child dependencies are elegantly handled with visual techniques in the Kanban Method

Kanban offers us simple yet powerful techniques for visually managing dependencies

5. Kanban frees us from time constraints to limit scope and batch size

The use of WIP constraints to achieve the same goals of quality,  focus, and short delivery times, like time constraints, removes the need  to analyze and break work down to detect dependencies in advance and to  share out large pieces of work across multiple teams, or multiple  sprints. The use of Kanban compared to Agile methods dramatically  reduces the demand for dependency management by avoiding the needless  creation of many dependencies.

6. Our approach to dependency management should be governed by the impact of delay

We should not have a single, homogeneous approach to dependency  management. Dependency management is expensive and should be subject to  economic tradeoffs; where the (opportunity) cost of delay is low, why  would you spend a lot of time, effort, and money, managing with the  intent to minimize the delay? We should use classes of dependency  management based on the class of service of the requested item and the  customer expectations for delivery to tailor our dependency management  approach appropriate to the risk.

We can use Triage Tables to determine the class of service of a  customer request, and only where the required class of service is Fixed  Delivery Date, or where there is a genuine deadline, should we spend  precious time and effort to detect dependencies in advance. We can use  class of dependency management, coupled to dynamic reservation systems,  and classes of reservation/booking, to ensure capacity is available when  it is needed.

7. Dependency management is much easier with thin-tailed lead times

When a customer-facing service has a thin-tailed lead time, the  required class of service for any given request is likely to be  allocated the Standard or Intangible (cost of delay) class of service.  This eliminates the need for heavy-handed, big analysis upfront,  dependency management.

When internal shared or platform services have thin-tailed lead  times, this enables the use of simple capacity allocation techniques for  dependency demand, ensuring that capacity is available when needed, due  to a just-in-time dependency discovery in a standard or intangible  class of service customer request.

Summary

To massively simplify dependency management, it is necessary to  instrument workflows to report lead time. Actions should be taken to  trim the tail of the lead time by improving issue management,  escalation, and resolution. Driving towards thin-tailed lead times has a  double payoff: less urgent, lower risk classes of service can be used;  techniques that rely on Little´s Law such as capacity allocation using a  WIP limit can be used.

The use of time-constrained sprints to limit batch size, create a  sense of urgency, and improve initial quality, is counter-productive, as  it creates a huge additional overhead and demand for dependency  management. Instead, deploy WIP constraints and remove the timeboxes.

Understanding the cost of delay and the appropriate class of service  for a customer request is a prerequisite to better, cheaper, less  impactful dependency management. Use Triage Tables to achieve this quickly and easily (even better try the Menta Triage application to calculate the class of service).

Dependency management policy and treatment should vary according to  the cost of delay, risk, and customer expectations. Use the class of  dependency management to determine the right approach.

Dynamic reservation systems with classes of booking, provide the  flexibility to respond elegantly, with minimal disruption, to any  dependent service request.

Conclusion

In conclusion, most organizations we observe can avoid up to 85% of  their dependency management overhead through the use of these  techniques. For organizations deploying the Kanban Method, dependency  management is almost a non-issue. Kanban copes with dependencies  elegantly and cheaply.

To learn how to better manage prioritization of work and dependencies join us for an upcoming Kanban for Design and Innovation course. Learn about upstream Kanban and how to work with both the triage and dependency management posters.