Managing cross-team dependencies is one of the most challenging tasks an Agile team has to take on while operating in a multi-team or scaled business environment. Doing it wrong, your team might suffer many organizational dysfunctions and politics: missed deadlines, endless meetings, and chaotic context switching.
Before deep diving into the article, I want to make clear that cross-team dependencies are not always necessarily a bad thing. Quite the reverse. We don’t want a company made up of totally independent teams. We wish for rich user experiences built up of cohesive capabilities offered by diverse groups. Without interactions between squads, we might have a highly fragmented user experience.
The tricky part is to find the right balance. Not all dependencies are created equal, or that they are inevitable. Some dependencies are the outcome of poor and overly complicated organizational design. Others, however, are necessary for efficient cooperation, risk management, or technical considerations. Hence, it’s not our ultimate goal to eliminate all dependencies.
Now, let’s go into detail about different types of dependencies and explore the plethora of strategies to help us minimize the pains of cross-team dependencies.
Types of dependencies in Agile teams
No product development project operates in a vacuum. In most projects, dependencies arise – between teams, phases, functions, or people. It’s essential to distinguish between them in order to practice efficient dependence management.
Here are several elements Agile teams can deploy to classify dependencies:
- Whether internal or external
- Whether mandatory or discretionary
- The nature of the dependencies
Internal vs. External dependencies
Dependency Type | Explanation | Example |
Internal | Dependency is under the team’s control and is based upon the connection between work activities. | The engineering lead delegates a frontend developer to start creating a mobile app using HTML. |
External | Dependency is outside the team’s control and built on relationships between groups, functions, or enterprises. | The dev team has to wait on hi-fi wireframes from the design team to start building the app. |
Mandatory vs. Discretionary dependencies
Dependency Type | Explanation | Example |
Mandatory (hard logic) | One action must be completed before performing another action. | Codes must be created before they can be tested. |
Discretionary (soft logic) | It’s best to complete one phase before another, but not necessarily demanded. | Product should be completed before launching a marketing campaign. |
Dependency function
Dependency Type | Explanation | Example |
Finish-to-start (FS) | Task 2 can’t initiate unless task 1 is accomplished (most common dependency types). | Feature requirements must be defined before development can begin. |
Start-to-finish (SF) | Task 1 can’t complete until task 2 is begun (the least common type of dependency) | The Statement of work and NDA must be approved and signed by both parties to close a project deal. |
Start-to-start (SS) | Task 2 can’t begin until task 1 has started, but task 1 does not have to be done before task 2 can start. | App features must be developed before testing can initiate, but not all features have to be developed for testing to commence. |
Finish-to-finish (FF) | Task 2 can’t conclude until task 1 is finalized. Tasks that have a SST dependency can also have a FF dependency. | App features development must be finished for the testing to be accomplished. |
Other dependency types
Dependency types | Explanation | Example |
Requirement dependencies | Dependencies occur due to the requirements of the project being defined. | When the team is unclear on a feature requirement but the person with the domain knowledge (product owner, project manager, etc.) is not immediately available to resolve it. |
Expertise dependencies | Dependencies prevail as the work demands certain expertise of a subject matter expert | Getting instruction from a database admin on a schema change |
Activity dependencies | When work can’t proceed until a related external activity is finished | Development environments must be provisioned before work can execute. |
Business process dependencies | When a business procedure influences your team’s ability to finish its work. | Change review board (CRB) approvals or compliance reviews |
Technical dependencies | When a task necessitates making technical modifications to a component of the system that is not under the team’s control | If the API isn’t properly versioned, your requested change might also demand adjustments to other downstream consumers, increasing the dependency. |
Why do dependencies emerge?
There are some common driving forces of dependencies between teams:
- Incomplete cross-functionality: As the team lacks one or more skills, it must rely on another team to compensate.
- Excessively complex architecture : These prevent the formation of cross-component and cross-functional squads. A microservice for everything, each managed by a different team, leads to a rise in potential dependencies.
- Implementing big design up front (BDUF): when plans change, your team might be in line with the project’s requirements.
- Legacy systems and processes: These can centralize information and prevent the establishment of cross-functional teams
- Regulatory requirements: When only specific teams or team members have access to particular data or systems
Minimizing dependencies via organization design
To lessen dependencies, several firms have employed these two techniques:
1. Slide and Scatter
We divide a bottleneck capability (a team and its technical components) among groups that depend on it.
For example, I’ve seen companies across industries having a dedicated rules context. This is frequently implemented using some sort of generic rules engine or BPM system. As a result, most business capabilities are anemic and call off to the rules department to check business rules. Hence, the rules team becomes the bottleneck, having several teams waiting for them to make adjustments. So, if possible, it’s recommended to separate the rules context into smaller sub-components and move those into the contexts that depend on them.
2. Slice and Merge
We identify the sub-parts of various capabilities that co-change and merge them into a new capability owned by a new squad.
A typical example of this technique is moving from activity-oriented teams (frontend, backend, DBA, etc.) to vertically-sliced capability teams.
Establishing resilient organizations
As mentioned above, we can’t wholly eradicate dependencies. And sometimes they are short-lived in nature, it would be pointless to rebuild our organization.
Instead, we can concentrate on generating resilient organizations that can comfortably cope with cross-team dependencies using the following strategies.
Inner sourcing
InnerSource is a software development method that utilizes open-source best practices for proprietary code. This technique is gaining popularity in corporations of all sizes. Pioneers like PayPal, Bosch, Bloomberg, and SanDisk have achieved incredible results with this technique.
When teams implement InnerSource, they create proprietary software and share the work internally between teams. This way, everyone – from developers to product managers – can contribute to the code.
By setting the default to open for projects, businesses can encourage team collaboration, reduce redundancy, and reuse existing solutions while tapping into the whole workforce’s talent.
Regular rotation
Based on our experience, regular rotation alongside technology standardization enhances the advantages of inner sourcing and lower costs.
Regular rotation involves moving people between teams regularly to give them a broader perspective than what they’re currently working on. When a cross-team dependency arises, the frictions of inner sourcing will be lessened by familiarity with that team’s systems and strengthened interpersonal ties due to rotating. 2-3 months is an ideal time to switch members to different groups.
Temporary pairs and other resilience patterns
We also have access to different resilience patterns when building on a foundation of regular rotations. We could, for instance, establish a temporary pair. To handle the dependency, a member of team A and a member of team B may temporarily work together.
Beyond the practices, there are essentially some dials we can adjust, balancing coordination/learning/opportunity/duplication/etc. costs for the many teams involved, giving us access to various patterns.
For instance, when attempting to create something novel that cuts across multiple teams within a large corporation, we can assemble a short/mid-term discovery team composed of several members from each squad.
In this case, we’re compromising alignment with team members who weren’t transferred to the temporary team to optimize for innovation on the new capability, as we have a single squad that can move quickly.
This pattern, often referred to as an enterprise discovery context falls under the broader category of isolated innovation patterns.
Another popular pattern is the micro teams pattern, where overall teams are more significant, and individuals within them continuously form/reform sub-teams depending on the available work.
Forecasting cross-team dependencies
In our experience, it’s always better to plan for dependencies that are likely to occur. Nevertheless, there is a great difference between shallow and deep anticipation.
Shallow anticipation
If we anticipate certain dependencies, we can set up lightweight controls that allow us to react more effectively in the event that those dependencies emerge.
For example, we can promote member rotation between teams that are expected to have dependencies in the future. Accordingly, we would aim for higher levels of rotation in a layer 2 capability or a tribe in Spotify Model lingo
You can utilize visualization approaches like EventStorming, value stream mapping, and portfolio Kanban boards to assist us in foreseeing possible dependencies.
Deep anticipation
Occasionally, the cost of dependencies is so high, and their chance of forming is so sure we need to plan in advance and proactively coordinate the activities of various teams.
The Waterfall lies at the extreme end of deep anticipation. Some argue its largest disadvantages is its reliance on significant upfront predictions and long-term stability while software development is relatively complicated and unpredictable.
Deep anticipation is another dial we might tweak to suit our needs. It’s neither good nor bad. But the more we crank it up, the closer we are to Waterfall, no matter what fancy name we give to our process.
Making compromises
Finally, there is a harsh reality we all must face: not all work is created equal. When teams are blocked, sometimes, it is in the company’s best interest for them to remain blocked to prevent delays in high-priority initiatives.
It won’t be a pleasant experience, though. We all have our team objectives but we have little chance of achieving them. However, in some instances, the firm strives to remain competitive and has to put all its resources behind a crucial endeavor.
Stop fretting about teams being obstructed. And even if all of your employees are not fully utilized, you shouldn’t be concerned. When being blocked is advantageous for your enterprise, seize the chance to strengthen organizational resilience.
A Heuristic for Managing Dependencies
My approach when managing teams and providing clients advice is to optimize for resilience and remove bottlenecks, reverting to deep anticipation only in extreme cases.
I want every team member to feel free to approach problems however they see fit. When we plan for the future and put controls in place, we commence to diminish autonomy and give power back to higher echelons of the company.
Do You Need A Hand?
Cross team dependencies can cause immense distress and conflict. The more dependencies involved in a feature, the less chance it will be completed by the deadline. To effectively mitigate and manage them, companies would have to streamline the flow of work and realign people and teams around value streams. Mastering this requires lots of time and effort.
A great way to speed up this process is to partner with a highly-skilled IT service provider like KMS Solutions. With years of experience and expertise in the software industry, our team has helped multiple clients transform their Agile teams and deliver a better software development process. Talk to our experts now
