Spend your political capital to remove organizational barriers.
There are five prior posts in this series on dependency breaking:
- Introduction: Presented the case for removing dependencies to support the Agile mindset and drive control into the Agile team.
- Task Level Part 1: Supplied a simple pattern that keeps tasks within the team—the cross-functional feature team.
- Task Level Part 2a: Provided context for common anti-patterns that impede a team from finishing what they start.
- Task Level Part 2b: Outlined how vertically sliced stories and swarming can combat the desire to start something new versus finishing what was started.
- Feature Level: Illustrated how teams can avoid feature specialization by owning end-to-end use cases across features, reducing feature-level dependencies.
In this final post, we wrap up the discussion by describing how to break organization-level dependencies. Organization-level dependencies occur when a team depends on another team from an external organization to deliver a feature to a user.
Examples of organization-level dependencies include:
- Layer Teams: Coordinating with an external database team to maintain database elements required for a feature.
- Single Phase Teams: Engaging with an external testing team to perform integration testing or user acceptance testing.
- User Experience Teams: Interfacing with a user experience research team to understand user needs for a feature before development or to perform user testing on a developed feature.
- Downstream and Upstream Teams: Depending on downstream product teams to perform further processing on the output of a feature or with upstream product teams to provide input to a feature.
- Approval Boards: Engaging with an approval board before releasing features into production.
Like other dependencies, organizational entity dependencies can bring significant waste to your delivery teams, impeding their ability to effectively and efficiently deliver value. Organizational entity dependencies can be a bit more difficult to break as they typically require political capital to be spent and test organizational and hierarchy boundaries. A team often has limited ability to make this happen.
Below we discuss one anti-pattern and three corrective patterns for dealing with the above types of organizational entity dependencies.
Anti-Pattern: Coordinate and Plan Better
With external dependencies, teams tend to attempt to coordinate more closely with the entities and plan better. The ability to plan better amidst the uncertainty inherent in software development is a false belief.
Teams conduct coordination workshops, such as Big Room Planning, to bring all dependent entities together to highlight and coordinate interdependencies. Large, impressive walls result from the workshop, filled with feature maps and strings to tie together dependencies. Teams form a contract where each dependent team agrees to a plan to deliver their part by a certain date.
The teams leave the workshop, and within days or hours, the dependency plan is out of date. It is often too expensive or logistically impossible to get all dependent parties back in a workshop to replan.
Typically, management puts controls and communication mechanisms in place to inform of changes or to approve them. Sometimes, teams adjust and can adhere to the changes, but more often than not, teams cannot make the appropriate adjustments.
Each team has its own priorities, and they are often not the priorities of the team that depends on them. There simply may not be enough time to adjust to the changes. Maybe a team misinterprets the change or the change does not come to the team’s attention. In the end, the ball gets dropped, and changes do not get addressed appropriately or promptly.
When changes cannot be accommodated, blame sets in. Statements, such as the following, may be heard:
- “The external team said they would finish last week. They missed the mark.”
- “This is their fault, not ours.”
- “Delivering is out of our control. Ask the external team when they will complete the work. Our hands are tied.”
- “We did our part. Now it is in the hands of the external team.”
- “I assumed you would be delivering when you said you would in the Big Room Planning workshop. Now you are not! We need your work ASAP!”
The less control your teams have over their work, the more they will need to coordinate. The waste exponentially increases with each coordination point. At some point, your team will become beholden to managing and coordinating dependencies. Delivery of value slows to a crawl. Coordination fails.
More details on the waste inherent in dependency coordination can be found in the first post of the dependency-breaking series.
Corrective Pattern 1: Utilize Dependency Breaking Strategies
In the first post of the dependency-breaking series, the dependency-breaking strategies in Figure A were introduced:
Option 2 and 3 are valid ways to avoid the waste of coordinating dependencies. However, the most powerful strategy is to choose option 1. Option 1, “Do It Their Way”, assumes that your team develops the dependent item themselves. Option 1 typically requires upfront and ongoing coaching from the external team. The external team will need to coach on their standards and help your team set up to work in their environments before work commencement.
Once work begins, the external team will provide 1 – 2 team members to pair with your team during development as shown in Figure B. After your team becomes more adept at developing in the external team’s environment and the external team builds trust in your team’s capabilities, the external team members may no longer need to pair with your team.
Option 1 is not easy as the external team typically does not want to relinquish control over their product code base to another team. The external team will express quality concerns, but these can be easily overcome by the external team coaching on standards, ensuring correct environment configuration, and coaching through cross-team pairing.
The more difficult concern to diffuse is the apparent loss of power. Due to this perceived loss of power, management needs to build a bridge with the external team. The “Management Builds a Bridge” corrective pattern below describes this in more detail.
Corrective Pattern 2: Management Builds a Bridge
As a manager, this is how you serve the team. They don’t need help with what is in their control. They need help with what is out of their control. In most cases, the team does not have the relationships or the power to build bridges between organizational entities and break dependencies.
As a manager, you have the relationships and the political capital to spend to break dependencies with external teams and increase the control your team has to deliver value directly to its users.
Sit down face-to-face with the external teams and their management. Listen to their concerns. Form and agree to an operating paradigm with the external team that they are comfortable supporting and addresses their concerns.
Refer to How to Shift Gears to Become an Agile Leader for more details on this technique.
Corrective Pattern 3: Remove Dependencies Due to Over-processing
We have all been in a situation where we have to obtain an approval or other processing from an outside entity before claiming victory. Many times, these additional steps are in place to guard against a repeat occurrence of a costly historical incident that is unlikely to occur today. We become accustomed to performing this activity without questioning its relevance. Consequently, a checklist mentality develops where we just do something because we have always done it that way.
A small shift to question every process step to determine if it is adding value will help avoid unnecessary processing waste. There is no need to break the dependency if you can remove the activity altogether.
As a manager, you can use your political capital and relationships to remove these unnecessary steps. Make the case to external entities that steps are no longer necessary. Unfortunately, this will not be an easy task especially if governance is ingrained into corporate culture. You don’t have to convince the external entity to remove the step for the entire enterprise. Perhaps the entity will give your teams a pass and not other teams. You can still count this as a win, and it will give your teams more control to expediently deliver value.
Conclusion
Keeping control within a team is critical for the expedient delivery of value. This final post rounds out the series on dependency breaking. Reducing organizational entity dependencies by bringing capability into your team or by removing unnecessary steps will increase your team’s control over delivering value. As a manager, you can serve the team by building the bridge with external entities to break dependencies or remove unneeded process steps.
Consequently, as a side benefit, teams get a wide range of experience across the entire value stream required to ship value to their users.
I hope you have enjoyed this series on dependency breaking. Please share your experiences with dependency breaking.
Other Posts in the Series
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.