Agile squads are supposed to be cross-functional, atomic, and capable of delivering a product to the end user completely independently. However, as an organisation scales and the product becomes more complex, it is often necessary for squads to work together to deliver an increment of value.

Because squads are set up for independence, having them rely on one another can cause friction, which ultimately delays projects. This was a problem the team I work with noticed several months ago. We found that of the sprint goals we missed in the previous 29 weeks, one in three were due to an external dependency.

So in the spirit of continuous improvement, we made a commitment to surface known or possible dependencies as soon as possible and formulate strategies to deal with them, should they arise. In the following 13 weeks to date, we have missed zero sprint goals due to external dependencies and are actually completing 35.2% more sprint goals than we previously were.

This article details the strategies we used to achieve this.

Feel free to skip ahead and read about the strategies now, or read on to first understand what dependencies are, where you might see them surface in your organisation, and how you should plan in the long term to remove them at their source.

What Do We Mean By Dependencies?

Dependencies are things that need to happen for an Agile squad to complete an increment of value, but that cannot be achieved by the squad alone. Dependencies, if not handled correctly, lead to blockers in task execution.

In scrum, the product backlog is the main planning tool used to inform the direction of the squad. Broadly speaking, the product backlog consists of tasks (often called stories or user stories) with well-defined acceptance criteria. A good user story is scoped and written to follow INVEST (independent, negotiable, valuable, estimable, small, and testable).

The concept of independence is key to the idea of managing external dependencies. If a piece of work is completely independent, it has no dependencies whatsoever. While this is something we should strive for, it is not always attainable. There is value in cross-functional, cross-vertical initiatives, and so we must plan for and manage dependencies.

Types of Dependencies

Requirements dependencies — When the squad 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 — When assistance from a person with specific know-how is needed in order to do something, for example, getting guidance from a database admin on a schema change
Activity dependencies — 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 work can begin
Business process dependencies — When some existing business process affects your squad’s ability to complete its work, such as change review board (CRB) approvals or compliance reviews
Technical dependencies — When work requires technical changes in an area of the system that is outside the squad’s control, for example, when you need changes to an API that is managed by another squad. This can be compounded by tight coupling. Let’s say the API is not strictly versioned — now your requested change might require changes to other downstream consumers as well, which means even more dependencies.

Why Do We Want to Eliminate Dependencies?

Simply put, the more dependencies involved in a feature, the less chance it will be completed by the end of the sprint, quarter, etc. This is a problem since you always want to minimise the cycle time of feature development, to deliver for your users as soon as possible.

It also affects your ability to react in an agile way to changing market conditions. Increased cycle time and a loss of agility manifest themselves as organisation stress.

A natural reaction to this stress is to “divide and conquer”; splitting the organisation up into squads which can deliver the features we know we need today. While this removes the dependencies in the short run, it does not help with tomorrow’s dependencies.

Additionally, waiting around for others to complete work or being pressured to complete work for others is harmful to organisational morale. For these reasons, in an ideal world, scrum teams should have no dependencies.

“Cross-functional squads have all competencies needed to accomplish the work without depending on others not part of the team. The squad model in Scrum is designed to optimise flexibility, creativity, and productivity.” — Scrum Guide 2017

Why Do Dependencies Arise?

We would like to cut off the dependency problem at the source. There are some common root causes of dependencies between squads:

Organisational structure — The Android squad, the testing squad, etc. Clearly this is not cross-functional. If the Android squad cannot make a change to API they rely on, they are blocked.
Incomplete cross-functionality — If squads lack one or more skills and must rely on another squad to provide it
Unreasonably complicated architectures — These inhibit the creation of cross-component and cross-functional squads. A microservice for everything, each owned by a different team, results in an exponential increase in the number of possible dependencies.
Doing big design up front (BDUF) — When plans change (and they will change) you may find your squad is not aligned with the requirements of the project.
Legacy systems and processes — These often centralise knowledge and inhibit the creation of cross-functional teams.
Regulatory requirements — When only certain squads or squad members have clearance or access to certain data or systems, it creates dependencies.
Resistance to change — Dependencies often justify the existence of a squad. There is a natural resistance to process or organisational change that threatens this.

The Long-Term Plan: Eliminating Dependencies

Agile assumes the squad has everything it needs to deliver an increment of value. In an ideal world, we would have cross-functional squads with all the know-how and permissions to build, test, and deploy a product end-to-end with minimal interactions between them.

However, this isn’t always possible, at least not immediately. Regulatory requirements, organisational structures, knowledge silos, and resistance to change often prevent squads from breaking dependencies entirely.

In the long term, the solution lies in applying Lean Thinking, Kanban, and the Theory of Constraints across squads, to manage the flow of work and realign people and squads around value streams rather than functional areas.

In the short term, we can mitigate dependencies by calling them out as soon as they are known and manage them using the strategies below.

11 Strategies to Mitigate Dependencies in the Short Term

The strategies can be split into two categories, with most falling into both.

Strategies to mitigate dependencies into the squad:
Strategies to mitigate dependencies onto other squads:

Strategies to mitigate dependencies into the squad:

1. Automation

Where possible, automate repetitive tasks, with appropriate controls in place for safety. Things like continuous integration/deployment (CI/CD) or automating repetitive support tasks would be examples of automation that removes or mitigates dependencies.

2. Standardise processes

If automation is unfeasible, make processes happen the same way each time to eliminate planning and coordination.

Strategies to mitigate dependencies onto other squads:

3. Gatekeeper strategy

Prevent dependencies from affecting the squad’s throughput by blocking stories with dependencies from entering the sprint until you are reasonably sure that dependencies will be resolved in time.

4. Micromanage

If your dependency requires significant work to resolve, work proactively with the downstream squad to ensure this work is planned and executed ahead of time.

5. 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.

6. Remove the dependency from your scope

Unblock yourself by faking it! Set up test stubs or create dummy infrastructure to complete your side of the work. By delivering on your commitment, you have decoupled yourself from the requirement that the dependency is deployed. This works well in conjunction with formal engagement models as long as squads maintain alignment.

Strategies to mitigate dependencies both into and onto squads:

7. Utilise Agile ceremonies

Check-ins — Set up recurring (for the duration of the project) check-in meetings with the teams you depend on or who depend on you, to keep the shared requirements front of mind.
Stand-ups — Attend their stand-up when it makes sense to, and with their permission. Or have them attend yours. Consider a scrum of scrums.
Project retrospectives — Critically evaluate what can be improved about your collaborative efforts. This is particularly valuable to facilitate a long-term or recurrent engagement.

8. Align on common goals

Invite the relevant squads to design reviews, project planning meetings, check-ins, or retrospectives to give them an insight into the work that you do, why it is important, and how it aligns with the company’s top-level goals. Take an interest and learn about their incentives and concerns.

9. Use virtual teams

If the work required is complex or tightly intertwines each squad’s systems, then you should consider the merits of forming a virtual squad for a period of time. You could also second someone or have someone seconded for the duration of the project.

10. Report on flow metrics

Surface burndown and velocity charts which show the impact of dependencies (into and out of the squad). This can be a powerful impetus for change. Consider bringing these results to reviews with stakeholders to resolve dependencies together.

11. Employ formal engagement models

Squads should draft engagement models with service level agreements (SLAs) around common request types. Within an organisation of sufficient scale, this will often make sense as the overhead of drafting these models is offset by the frequency of their use.

Hopefully applying these strategies and surfacing dependencies early will make your life easier when collaborating with other Agile squads to deliver value for your customers.

Originally published on medium.