I once visited a Labyrinth in France many years ago. We spent hours trying to figure out where each path would lead and how to find our way out. It was time-consuming, frustrating, and, at times, even a little scary.
Now imagine running a relay race inside that Labyrinth. A relay is a team sport. No matter how fast one runner is, the team cannot finish the race unless the baton is passed smoothly from one runner to the next. Each runner needs to know who they are receiving the baton from, when to expect it, and which direction to take once they have it.
That is what dependency management can feel like in Agile delivery in large scale organizations: multiple teams running a relay together through a Labyrinth.
How do we reduce the impact of the dependencies in scaled agile delivery?
To explore this, I want to take a real-world example from a company I worked with as an RTE.
The company provides internet and mobile services to its customers. Broadly, customers interact with the company through two major routes: Assisted and Digital. One product capability that cuts across almost all these channels is Offers.
The company regularly provides different offers and promotions to customers, particularly around holidays and major campaigns. While defining an offer and making it available may sound straightforward, the business complexity increases because the same offer may have different eligibility rules, pricing, benefits, or availability across customer channels. An offer available through POS might not be available through Telesales or Door-to-Door. As a result, a single business promotion could require different decisions and implementations across multiple channels, creating dependencies between Product and technology teams.
Dependency on Product and Technology Teams
Product teams had to define which offers applied to which channels, customer eligibility, priorities, timelines, and channel-specific variations. Technology teams then had to ensure the right offer was displayed in the right channel based on these rules. The complexity increased because different teams owned individual technology components—such as the offer engine, channels, customer information, and downstream services—creating dependencies across the technology stack.
As a result, delivering what appeared to be a relatively small customer-facing change could require coordination across several teams.
The underlying root cause was the way the teams were structured. Teams were working in silos, owning only a component or piece of technology, and feeling responsible primarily for that part. The long-term solution would be restructuring the organization. But we couldn’t wait for that transformation to happen.
Customers don’t wait, and holidays don’t wait.
We had to work with the existing systems and organizational structure to manage these dependencies. We had sophisticated tools available to us—JIRA, Confluence, Kanban boards. However, tools don’t solve problems; they help us make problems visible.
It is the people who need to understand the problem, come up with solutions, and implement them.
Once we understood what was happening, we came up with an action plan.
1. Bring Product Teams and Agile Teams Together
Product Teams and Agile Teams needed to work together. We asked for dedicated resources from each component team to work on this project with some shared services like Devops, Security, Marketing etc. This reduced the need for people to wear multiple hats and allowed the teams to focus. We asked both our Engineering Leads and Product Teams to work together to identify the list of offers and the dependencies on other teams.
This was our first step into the Labyrinth: bring in the people who know the terrain and start drawing the map.
2. Identify Dependencies During Refinement
Instead of waiting for conversations to happen during Sprint Planning or Standups, we asked our Product Owners to start discussing dependencies during refinement sessions. Before pulling a story into the Sprint Backlog, the team needed to understand the dependencies, identify the owners, and agree on how they would be managed.
This responsibility fell upon both the Product and Engineering Leads.
This was where we started calibrating the map—understanding the path ahead, identifying what we needed, and making sure we knew what stood in our way before entering the Sprint.
To ensure complete alignment across all workstreams, we guided the teams through a detailed review of the various dependency types.
| Dependency | Team’s Example | Baton Example |
|---|---|---|
| Finish-to-Start (FS) | API team must complete the API before the UI team can start integration. | “I can’t start my run until you finish your leg and hand me the baton.” |
| Start-to-Start (SS) | Once the development team starts development, the QA team can start preparing test cases and test data. | “Once you start running, I can start my run too. We don’t need to wait for you to finish.” |
| Finish-to-Finish (FF) | UI and API teams can work independently, but the feature cannot be completed until both pieces are finished. | “We can run our legs at the same time, but we both need to reach our checkpoints before the race can be considered complete.” |
| Start-to-Finish (SF) | A legacy system can be decommissioned only after the replacement system has started operating. | “I can’t finish my leg until you start yours.” |
3. Make Dependencies Visible Through Our Tools
If a story had a dependency, the dependency field in JIRA had to be updated, and a sub-task had to be created and assigned to the person who would be working on that dependency.
We could also use the Kanban Board by creating Parent-Child stories and Planview by linking the EPICs, Features, and User Stories that had dependencies on each other.
These tools became the markers along the path, helping us see where dependencies existed and giving us greater visibility into the route ahead.
4. Bring Dependent Teams Into the Conversation
Additionally, we ensured that cross-team members contributing to the task were identified early, brought into alignment, and agreed upon a target date for delivering the code to the SIT environment.
This was much like passing the baton from one team member to the next. The next person needs to know when and where the baton is coming so that the race doesn’t stop.
A good handoff requires more than simply knowing that another team has something we need. Both teams need to understand what is required, who owns the handoff, when it needs to happen, and what happens next.
Identifying the Critical Path
In a complex delivery involving multiple teams, some activities can happen in parallel while others are dependent on one another. The critical path is the sequence of dependent activities that takes the maximum time to reach the end. Any delay in one of these activities can directly impact the overall delivery timeline.
For example, in our Offers scenario, the path could look something like:
Define Offer → Finalize Requirements → Develop API → UI/Channel Integration → SIT/UAT → Business Approval → Production Deployment
At the same time, other activities such as campaign preparation, analytics setup, security reviews, or supporting activities may happen in parallel.
In a Labyrinth, knowing every possible path is useful. But knowing the path that determines when you reach the finish line is critical.
5. Actively Follow Up and Collaborate
We encouraged our Scrum Masters to follow up on these dependencies and identify escalation paths to raise concerns when needed. We also encouraged our developers to do peer review before deploying the code.
This helped us correct the course when we realized we were heading in the wrong direction, rather than discovering the problem at the end of the race.
The goal was not simply to track the dependency. It was to make sure the baton kept moving.
Lessons Learned
The biggest lesson for me was that dependencies cannot always be eliminated, but they can be made visible, understood, and actively managed.
The goal of dependency management isn’t to create a better dependency tracker. It is to create a delivery system where teams know who has the baton, when it needs to be passed, and which handoffs can delay the race.
A tool can help us draw the map, but it is the people who need to understand the route, communicate with each other, and pass the baton at the right time.
In large-scale Agile delivery, dependency management is therefore not just about tracking dependencies. It is about creating clarity, collaboration, and shared ownership around them.
We may not always be able to remove the Labyrinth.
But we can make sure our teams have a map, know the route, coordinate the handoffs, and keep the baton moving toward the finish line.
Leave a Reply