Building Interoperable Teams

To build interoperable teams, leaders must eliminate or mitigate cross team and system dependencies while fostering strong relationships and communication between teams.

A mantra that has resonated with me is “at scale, everything breaks," attributed to Distinguished Google Fellow Urs Hölzle.  I believe a far more interesting mantra is “Anything that needs an agreement breaks at scale." Cross team dependencies and complex system interfaces breed defects and lead to long solution delivery timelines in enterprises much smaller than Google.

I have been blessed to work in environments for several years that are agile / hybrid / transitioning to agile and am thankful for all that I have learned along the way. One pattern I have noticed is the correlation of a team’s effectiveness relative to managing its dependencies (both organizational and system dependencies). Teams that are able to drive continuous improvement through the lens of self-sufficiency find paths to maturity and higher velocity.

Let’s examine 3 different states of team maturity: Dependent, Independent, and Interoperable teams:

Dependent Teams

These teams must negotiate multiple cross team agreements and align with other teams’ sprints to deliver each feature.  At first, dependent teams may not be fully aware of how dependencies may impact delivery; furthermore, they may not have effective agreements in place to manage these dependencies.  Dependent teams often experience story carry over and missed commitments. Do any of these seven drivers of dependent teams sound familiar to you? 

1. Software Development Life Cycle Dependencies – Dependency on other teams for environment support, code management, release management, testing, deployment, or other functions to support software engineering.
2. System Architecture Dependencies – System to system interfaces are tightly coupled, or have complex interfaces / agreements.  Systems and data not built to target architecture.
3. Application Architecture dependencies – Platform is “over” built with unnecessary technology layers, languages, or components that are difficult to maintain.
4. Enterprise Dependencies – requirements to use outdated enterprise applications or enterprise applications that otherwise don’t meet the needs of your line of business.
5. Infrastructure dependencies – Enterprise policies enforce use of existing data center which is constrained or has non-desired SLAs.
6. Process dependencies – Business process with multiple organizational hand offs, silos, or multiple human interactions.
7. Skill dependencies – The team does not have all the skills needed to complete a feature.

Independent Teams

Independent teams have figured out how to best manage dependencies.   First step is to identify and categorize each dependency or agreement to create a common understanding.  Mere awareness can be helpful inputs into team planning and communication. Second is to create action plans to address each one for the short and long term. Action plans can fall into the following categories:

1. Eliminate – Eliminating a dependency entirely can have a significant impact.  For example, a team that moves to a cloud approach might be able to eliminate dependencies it has on centralized environment teams. 
2. Simplify – Simplifying existing agreements through process improvement can lead to higher velocity. For example, moving to a real-time interface to onboard a new client or account might eliminate operational issues stemming from batch interfaces.  
3. Trade – Trading a complex agreement for a simpler or more local agreement can have advantages.  For example, migrating from an enterprise’s legacy support system to a new version or leveraging a local solution in your line of business instead might be the right answer.  
4. Mitigate – Not all dependencies can be eliminated or simplified.  Having a mitigation plan in place and working agreements will help smooth cross team interactions.

Independent teams have a sense of pride, craftsmanship, and leverage continuous improvement to lessen the impact of dependencies or eliminate them entirely.  Using a methodical approach and empowering the team can accelerate the path to agile maturity. 

Interoperable Teams

Being independent is not the end game. Has your team created positive working relationships with other teams as it worked through managing its dependencies?  Furthermore, is your team empowered to leverage those relationships to proactively solve problems?

Here is an example to illustrate the point: A front-end team which has built a solid customer facing solution wants to get to the next level of availability (say from 99.9 to 99.95 percent) to meet goals for a better client experience. The front-end team can’t do that alone even though it has mitigated its dependency to a back-end system and team via a thorough understanding of the interface. In addition, the back-end team may not understand how its nightly batch processing windows might impact front end availability nor may they be incented to change the process due to the existing operating model. If the teams can align goals, share ideas, and put the client experience first then a different conversation and solution can emerge. Those cross-team relationships the front-end team built with back-end teams might have the answers to achieve better business results.  

Teams that become interoperable see the results from building relationships with other teams. They no longer see those dependencies on other teams as liabilities to be mitigated or eliminated. Interoperable teams are the most successful, have the most fun, and produce the best products. Their approach to solve client problems is infectious and can influence other teams.

Have you seen teams master dependencies to reach higher velocity and effectiveness?   What techniques have been helpful?