How to Manage Agile Team Dependencies
Dependencies are things that need to happen in order for an agile team to complete an increment, but that cannot be achieved by the team alone.
For example, you might be dependent on the Ops team to perform deployments. Or perhaps you need assistance from a limited resource, such as a consultation with a DBA or a CRB review, before you can deploy a new feature.
When left unmanaged, dependencies can disrupt work and negatively impact developer happiness. They can also mess up your metrics.
Say, for example, your new feature requires an API change to another team’s service and your ticket sits in their queue for weeks. Dependencies like these make it hard for you to predict when your work can be completed; they interrupt your team’s flow, delay progress, and distract you from doing your work. It’s frustrating for team members when they can’t push work to prod and start collecting feedback from users because it’s sitting in queue.
The Long-Term Plan: Eliminating Dependencies
Agile assumes the team has everything it needs to deliver an increment of work. In an ideal world, we would have cross-functional teams with all the know-how and permissions to build, test, and deploy a product end-to-end with minimal interaction. However this isn’t always possible, at least not immediately. Regulatory requirements, org structures, silos, and resistance to change often prevent teams from breaking dependencies entirely.
In the long term, the solution lies in applying Lean Thinking, Kanban, and the Theory of Constraints across teams, to manage the flow of work, and realign people and teams around value streams rather than functional areas.
But what about in the short-term?
Mitigations in the Short Term
The ideal state is rarely achievable right away, but in the meantime we can adopt strategies to mitigate the effects of external dependencies while working in the background to break them. This way we can adopt Agile practices in an incremental way without requiring massive restructuring right out of the gate.
Before we look at how to manage dependencies, it’s useful to understand some of the different types of dependencies.
What Are the Different Types of Dependencies?
Requirements dependencies
Requirements dependencies occur when the team is unclear on a requirement, and the person with the domain knowledge (the product owner, stakeholder, program manager, etc) is not immediately available to provide it.
Expertise dependencies
These occur when assistance from a person with specific know-how is needed in order to do something. For example, getting guidance from a DBA on a schema change.
Activity dependencies
Activity dependencies are when progress cannot be made on a piece of work until an external activity is completed. For example, waiting for development environments to be provisioned before development can begin.
Business process dependencies
This type occurs when some existing business process affects your team’s ability to complete its work, such as change review board (CRB) approvals, or compliance reviews.
Technical dependencies
Technical dependencies occur when work requires technical changes in an area of the system that is outside the team’s control; for example, when you need changes in an API that is managed by another team. This can be compounded by tight coupling. For example, if the API is not strictly versioned, your requested change might require changes to other downstream consumers too, which means even more dependencies.
Dependency Timing
Dependencies can also be subdivided according to their timing.
Ongoing dependencies
Occurring regularly, such as every sprint, every week, etc. For example, dependencies on operations for production deployments, change management approvals, SecArch reviews, etc. These can benefit from periodic check-ins with the downstream teams, to ensure communication channels are open and priorities are aligned.
One-off dependencies
Dependencies that only happen once, e.g. a change needed from another team in order for a new feature to function properly. The “gatekeeper strategy” can be effective with these.
Schedule-driven dependencies
Dependencies that arise at a certain point in a project, such as needing Operations involvement toward the end of a project to coordinate how deployments will be carried out after go-live. These are frequently best managed by a coordinator role (a product owner, program manager, etc.) who can plan ahead, and loop in the needed resources at the appropriate time.
Compensating Strategies
Here are some strategies to mitigate the effects of organizational and architectural dependencies on a team's work.
Automation
Where possible, automate repetitive tasks, and include appropriate controls to ensure safety. For example, automate deployments, building in all needed safety and compliance checks, and let teams perform the process themselves, rather than having them back up in the Ops team’s queue.
Standardize processes
Even if you can’t automate a process, make it happen the same way every time, so you eliminate the need for ad hoc planning and coordination.
Employ formal engagement models
Have service teams draft engagement models with SLAs around common request types. Even if a process can’t be automated and run on-demand, at least consumers can reason about how long it will take within a range. This can be a high-overhead approach in small orgs, but may make sense in larger ones.
Create coordination roles
Create roles within the org to manage cross-team dependencies. This could be a scrum master, product owner, line manager, or in larger orgs a full-on program/portfolio management office. This pairs well with the Gatekeeper strategy (see below).
Gatekeeper strategy
Prevent dependencies from affecting the team's throughput metrics by not allowing stories with dependencies into the sprint until you're reasonably sure the dependencies will be resolved in time.
Until then, work offline to cue up the needed external work, so that when your work is pulled into a sprint you’ll have a high level of confidence it will be done in time.
- Plan everything you'll need from the downstream team up front
- List assumptions in the ticket
- Get assurances that downstream activities will be completed in time
- Raise potential risks to stakeholders as appropriate
Use tracking tools
Make dependencies visible in your planning tools. For example, create dependent stories in Jira or use color-coding to represent relationships on physical scrum or kanban boards. Use visual aids to shine a light on operational inefficiencies to bring about organizational change.
Report on flow metrics
Showing graphs and metrics of your team’s throughput, and quantifying delays that occur as a result of dependencies, can provide powerful visual impetus to drive change. Consider holding a quarterly review meeting with your stakeholders to review progress toward business goals as well as flow metrics for the team.
Micromanage
If your dependency will require significant work to resolve - e.g. a major network redesign is needed to provide necessary connectivity - work proactively with the downstream team to ensure this work is planned and executed ahead-of-time so it doesn't affect your lead time. This pairs well with coordination roles.
Do it yourself
Where possible, offer to do the needed downstream work yourself, or pair-program with the responsible party in order to drive it to completion. Along the way, look for ways to automate and normalize.
Remove the dependency from your scope
For example, if you are waiting on production environments to deploy your work, set up your own workspace in an environment you control (e.g. an ephemeral cloud account) to unblock yourself. Demo and deliver the working code, but decouple yourself from the requirement that it be deployed.
Check-ins
Set up recurring check-in meetings with the teams you depend on, in order to to keep your needs front-of-mind.
Standups
Attend their standup on a periodic basis, or have them attend yours.
Quarterly Retros
Meet quarterly to perform retrospectives of the relationship - things that went well, issues that arose, areas for improvement, etc.
Align on common goals
Host brown-bag, lunch-and-learns, etc to give the teams you depend on insight into why the work you do is important and how it aligns to the company goals. Take an interest and learn about their incentives and concerns as well.
In Summary
Dependencies can be highly disruptive to a team’s work, and can’t always be eliminated completely. As practitioners we need to find ways to manage their effects in the short term, while we work to break them in the long term.
