17 Kanban Dependency Management Hacks To Improve Flow Efficiency
Dependency management is perhaps one of the final frontiers to be conquered for Agile teams. Developing a deep understanding of Kanban provides you with a rich toolset to reduce the impact of dependencies to your flow.
There are generally two strategies for dealing with dependencies:
- Break the dependency
- Reduce the impact of the dependency on your flow
Break the dependency
“Don’t manage dependencies, break them!” – this is all well and good but for the majority of teams this just isn’t an easy option. Breaking dependencies often takes a long time involving significant organisational change or completely re-architecting your product(s).
The biggest blockers you’ll face in breaking dependencies are often the simplest of influences such as Conway’s Law, hierarchical management structures, monolithic architectures, specialisms, tribal traits, politics, empire building – the list goes on.
Another way to break dependencies is to build a cross functional team.
In a cross functional team all capabilities or skills required to deliver value is covered by one or more team members. Cross skilling all team members is not always feasible nor desirable. Specialisms play an ever growing important role in highly complex organisations.
Building teams made up of all the specialists required to avoid dependencies is often difficult, if not a non-starter for many organisations.
The Agile community talks about developing team members so they have T / 𝝿 / m shaped skills but this has its limitations.
The intent of building cross functional teams is to reduce the need to hand-off to other teams and improve collaboration. This works great for small organisations with say a single product development team. Go beyond this in terms of organisational scale and you’ll quickly hit the buffers.
Can you keep all team members engaged and productive in a truly cross functional team?
Imagine a team consisting of Full stack devs, DBA, network engineer, SAP HR specialist, devops engineer, mainframe developer, MS Dynamics dev, testers, legal specialist, marketing specialist. Do truly cross functional teams like this really exist in the wild? Highly unlikely.
All of these capabilities were required to deliver a single feature on a recent engagement. In reality, the single feature required dependency management across many disciplines and teams.
You need to recognise that your organisation is a network of interdependent services. Kanban embraces this and provides you with a method to optimise your organisation for end to end flow.
When you can’t BREAK dependencies, use Kanban to embrace the network of interdependent services to reduce the impact on flow by optimising for end to end delivery of value straddling departmental boundaries.
Portfolio Kanban
Take a deep dive into Portfolio Kanban on our instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.
Reducing the impact of the dependency on flow
This second strategy is well within the reach of most teams, especially when looking through the Kanban lens.
Waiting time (aka dwell time) is perhaps the 2nd biggest form of waste on any software project. Waiting time can be incurred in many ways. The most common forms of waiting time come from blockers, too much WIP, rework, dependencies, drag factors and weak system policies.
Understanding the downstream cycle time distribution is an important factor in reducing the impact of the dependency on flow.
Downstream teams are often completely blind to the fact they’re a dependency of an upstream team. Therefore, the team furthest upstream owns the entire dependency chain.
A Taxonomy of Agile Software Project Dependencies
In 2012, Strode & Huff published an awesome paper describing a Taxonomy of Agile Software Project Dependencies. In it they define three main types of dependencies. Here is an excerpt from that paper:
Knowledge dependency
A knowledge dependency occurs when a form of information is required in order for a project to progress. There are four forms of knowledge dependency:
- Requirement ‐ a situation where domain knowledge or a requirement is not known and must be located or identified and this affects project progress
- Expertise ‐ a situation where technical or task information is known only by a particular person or group and this affects project progress
- Task allocation ‐ a situation where who is doing what, and when, is not known and this affects project progress
- Historical ‐ a situation where knowledge about past decisions is needed and this affects project
Task dependency
A task dependency occurs when a task must be completed before another task can proceed and this affects project progress. There are two forms of task dependency:
- Activity ‐ a situation where an activity cannot proceed until another activity is complete and this affects project progress
- Business process ‐ a situation where an existing business process causes activities to be carried out in a certain order and this affects project progress
Resource dependency
A resource dependency occurs when an object is required for a project to progress. There are two forms of resource dependency:
- Entity ‐ a situation where a resource (person, place or thing) is not available and this affects project progress
- Technical ‐ a situation where a technical aspect of development affects progress, such as when one software component must interact with another software component, and its presence or absence affects project progress
Portfolio Kanban
Take a deep dive into Portfolio Kanban on our instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.
Below we take you through 17 flow efficiency hacks for dependency management. We’ve categorised each technique by strategy – BREAK or REDUCE. They are listed in no particular order.
Let's dive right in
1. Planning & Scheduling
Strategy: REDUCE
Somebody (usually a Project Manager) gathers time based estimates for all work items across multiple teams. They schedule the various work items to be completed in line with a plan and book resources accordingly.
This is possibly the most common and widely used approach across projects and teams. It’s also probably the most unreliable way to manage dependencies.
In my experience the odds of success of this technique are similar to a sevenfold accumulator!
Another really bad side effect of this approach is the inordinate amount of time wasted in meetings to support this.
2. Program Dependency Board
Strategy: REDUCE
Popularised by SAFe, the big program board makes a good job of visualising dependencies across teams and across time.
It provides a good visualisation to facilitate powerful conversations.
The biggest downsides observed with this approach are:
- Teams don’t always finish all planned work items in a given sprint so work items carry over to the next.
- The board therefore requires constant and regular updates.
- This maintenance activity is often neglected resulting in a pretty looking visualisation that quickly becomes useless or even misleading.
3. Visualise Blockers
Strategy: REDUCE
Blockers & Drag Factors. Visualising blockers goes hand in hand with dependency management. If you uncover or stumble across a dependency during dev use blocker stickers to raise the awareness then focus on unblocking.
Build upon this technique with blocker clustering to identify common internal or external blockers.
Identify which blockers can be avoided in the future by either reducing its impact or broken all to together.
Portfolio Kanban
Take a deep dive into Portfolio Kanban on our instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.
4. Reduce Systemic WIP
Strategy: BREAK
5. Monitor and reduce systemic waiting time
Strategy: REDUCE
When a team (upstream team) has a dependency on another team (downstream team) they will often send a request for work to be completed to the downstream team. This often manifests itself as a new task in the backlog (queue) of the downstream team. The task may sit in the backlog of the downstream team for a long time due to the downstream teams other priorities and commitments.
Find a way to measure the waiting time. You might do this by recording blocked/unblocked data points on the upstream teams blocker sticker.
Use this data to drive better conversations with downstream product owners.
6. Develop Self-Serve Capability
Strategy: BREAK
Why be dependant upon another team or individual?
Develop self-serve capability within the team to remove the dependency (self-serve). This depends on the type of dependency:
- Skills / People – if you’re dependent upon a particular person’s skills then invest time and effort into developing those skills within the team.
- Downstream team / Resource / Component – if the frequency of dependencies is high, work with the downstream team to find a way for you to self-serve and avoid the need to hand-off to them.
7. Systemic Swarming
Strategy: BREAK
In a multi-kanban environment (multiple delivery streams / teams) move people with the right skills between delivery streams to deliver the dependent requirements (so as to respect the release cadence) before returning to their own delivery stream.
There are a number of obvious prerequisites for this to work:
- The swarming staff have the right skills and knowledge of the code base
- The swarming staff have a relationship with the team and the team are happy for them to join them temporarily
- The added dev capability doesn’t create an imbalance in the downstream team and overwhelm, for example, testers
Portfolio Kanban
Take a deep dive into Portfolio Kanban on our instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.
8. Pull Requests
Strategy: REDUCE
Gone are the days of having the source code of an entire app sitting in a single code repository. Modern approaches to systems architecture often lead to many repos. Unfortunately, some organisations insist on strict lines of ownership of said repos across teams limiting access between teams.
This alignment of repos to teams often results in dependencies whereby if you want a downstream team to do work to resolve your dependency then you need to raise a work request with that team and wait for them to prioritise and complete the work.
Instead of doing this many organisations now operate an internal open source model.
Give access to all developers to all repos. If they make a change they have to create a pull request. The “owners” of that repo are then in a position to code review the change and approve/merge the change if appropriate.
If you have the skills to work on another codebase for which you’re dependent then pull requests are a potential way for you to reduce the impact of the dependency.
9. Fake Objects, Mocks, or Stubs
Strategy: REDUCE
If your team is dependent upon an API or component from another team, instead of waiting for that API to be available teams often stub or mock the interface to enable them to continue development.
- STUB – A placeholder implementation, returning defaults
- FAKE – A working, albeit trivial implementation
- MOCK – A simulated object that mimics behaviour
10. Queue & Wait
Strategy: REDUCE
Move the Story out of flow whilst you wait for the downstream team to fulfill the request. Once fulfilled return the Story to flow. This is shown in the “3rd party blocked” section in the Dev column above.
Note how the analysis done column runs all the way down the board, even across the 3rd party section. Therefore, when there is capacity in the dev column to pull work from Analysis Done, look all the way down the Analysis done column.
In the example diagram above, note how the limits are set for the flow of work above the 3rd party section. Often it is also worth while placing limits on the 3rd party section to prevent the 3rd party from becoming overwhelmed.
11. Backlog Visualisation
Strategy: REDUCE
Flagging up known dependencies earlier in the backlog to help with your selection policy. Embellish your cards with icons that represent the dependency type or use a checklist to make the dependencies visible.
Portfolio Kanban
Take a deep dive into Portfolio Kanban on our instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.
12. Manage both ends of the dependency
Strategy: REDUCE
Sticking a blocker sticker on your work item is a great start but just because you’ve done this doesn’t mean the downstream team know about it.
Make sure you can see your work request on the downstream teams backlog/queue. Make sure it’s prioritised appropriately. Discuss the work item with the Product Owner or Delivery Manager. Attend the daily stand-ups of the downstream team and monitor progress across the board.
13. Dependency Map
Strategy: REDUCE
The dependency map is a very common tool. Often it’s forms the centre point at a Scrum of Scrums meeting.
14. Use Explicit Policies to Expedite
Strategy: REDUCE
Agree an org-wide policy that anything arriving into “inbound dependencies” backlog row for each team is expedited or prioritised as part of the selection policy. Don’t use this for shared service teams as shared service teams are often faced with many upstream dependencies. This approach is more useful for component or feature teams.
The idea here is that if a work request somewhere in the system (org-wide system) is deemed high priority then all downstream dependencies should treat it as such and fulfill they’re dependencies as a matter of urgency.
Portfolio Kanban
Take a deep dive into Portfolio Kanban on our instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.
15. Re-Architect - don’t MANAGE dependencies, BREAK them!
Strategy: BREAK
A common mantra used is don’t MANAGE dependencies, BREAK them. This is good advice but it can take a very long time to break some dependencies.
To actually break a dependency may require you to change the fundamental architecture of your app or system. Further to this you may also need to restructure your teams to enable this.
16. Remove Environment Contention
Strategy: BREAK
When multiple teams share a common set of environments such as QA, SIT or UAT they often suffer from environment contention. That is, the inability to use an environment because another team is currently using it. Elaborate booking systems emerge which do nothing more than lock waiting time into process.
Break this environment contention by spinning up dedicated environments per team.
17. Merge Hell - Feature Toggles (aka feature flags / feature switch)
Strategy: BREAK
Feature toggles enable trunk-based development for teams practicing Continuous Delivery. Feature toggles attempt to provide an alternative to maintaining multiple branches in source code, such that a software feature can be tested even before it is completed and ready for release. Feature Toggles allow developers to release a version of a product that has unfinished features. These unfinished features are hidden (toggled) so they do not appear in the user interface.
Portfolio Kanban
Take a deep dive into Portfolio Kanban on our instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.
Dependency Management FAQ
Q) Who manages dependencies in an Agile environment where several teams are involved?
A) The furthest upstream team in the dependency chain should ensure all downstream dependencies are managed appropriately. This is because downstream teams don’t always know that a work request is a critical dependency.
Q) What about dependencies on management decisions / non-decision?
A) This type of dependency is a process dependency. Using a big bright blocker sticker on a Kanban board is a really good way to make the blocker visible. If you’re really brave, you could also add blocker metrics to the blocker sticker stating how long it’s been blocked.
Q) Can you recommend a tool to do serious and structured dependency management?
A) Sadly, this is where most of the mainstream work management tools such as Jira or Azure DevOps are really poor. The tools do support adding relationships between work items but I’m as yet unaware of any good visualisation plugins for these tools. If you find any, please comment below with the details.
Q) How do you forecast delivery dates on projects with many complex dependencies?
A) One simple method we use is to agree a tagging/labelling convention so you can uniquely identify work items associated with the project from across multiple teams. You basically create a cross team burn-up chart but just filtered for items tagged with your project or goal.
FREE ESTIMATION CHEAT SHEET
FREE KANBAN CHEAT SHEET
Brad Quirk has created a promising dependency visualization plugin for Jira – Dependency Mapper for Jira
Thanks Don, I’ll take a look.