What are the lessons we can learn from my recent article, The 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 can be avoided 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.