Gain Control by Breaking Dependencies — An Introduction

Don’t coordinate dependencies, break them.

When teams are struggling with dependencies, you might hear the following statements or something similar:

“The team we depend on is not ready, again”
“We can’t get our stories done because we are still waiting on the other team to fix the defects we found when integrating their code”
“That’s not our problem. The other team owns that.”
“We spent an entire week up front coordinating our work with our dependencies to avoid any problems. We still had problems.”
“It will take longer to deliver if we wait until the other team is finished. We should start in parallel and stub out what the other team is responsible to produce.”

This is an initial blog post in a series on dealing with dependencies. Having a strategy for dependencies is critical to ensure success with Agile. Every software development effort and every organization, large and small, have dependencies. Dependencies occur at multiple levels:

Between Tasks
Between Features / Stories
Between Teams
Between Organizational Entities

There are two ways to handle dependencies:

Manage / Coordinate them
Break them

This series will focus on strategies for breaking dependencies at each of the four levels above. Breaking dependencies is a corrective pattern for gaining control of your concept-to-cash value stream and enabling squad autonomy.

True, while working to break dependencies, you need to manage and coordinate where dependencies still exist. You might always require dependency coordination in certain situations.

This first post illustrates why managing and coordinating dependencies is a wasteful, expensive endeavor and should, therefore, be minimized. Also described are three general strategies for breaking dependencies.

The Dependency Coordination Anti-pattern

Outlined below is the dependency coordination anti-pattern that causes a loss of control and significant waste and delays.

Dependencies exist when one item depends on another item. The anti-pattern emerges with a tendency to believe that dependency coordination is a cost-effective, efficient technique for dealing with dependencies in an Agile organization.

Dependency coordination violates Agile values and principles and results in Lean wastes as described in the following sections.

Agile Values in Violation:

Dependency coordination violates every Agile value in the Agile Manifesto¹ as described below.

Individuals and interactions over process and tools

Dependency management and coordination add significant process and tool overhead to your Agile organization. It moves away from individuals and interactions working together and tends to create an “us” versus “them” mentality between the dependent entities.

Responding to change over following a plan

Coordination of dependencies requires significant planning to identify the dependencies and formulate a plan for when dependencies will be complete. In software, plans are fragile and they are often created when we know the least — before work has started. When reality changes during delivery, more planning is performed to further coordinate dependencies after missed deadlines. Usually, when things do not go as planned, the response to change is not sustainable since the project is usually behind schedule.

Many elaborate planning techniques and tools have been created to better coordinate dependencies and make them visible. Big Room Program Increment Planning in the Scaled Agile Framework (SAFe) is one such technique. However, these plans are just as fragile as every other software plan. While they do a great job of making dependencies transparent and aligning teams on how to coordinate, when the team hits the reality of the terrain on the ground, the plans quickly become stale. Getting everyone back into the big room to address the change is a logistical challenge. Even worse, responding to the needed change is difficult since many things are not in the control of the team when dependencies are in play.

Customer collaboration over contract negotiation

Dependencies stand in the way between what the customer needs and our ability to deliver solutions. Contracts start being formed between dependent teams — deadlines are set, the scope is defined, and the cost is estimated. Often, teams in the dependency chain become far removed from the customer. These contracts not only stand in the way of customer collaboration, but they also stand in the way of team collaboration. Teams form boundaries, hindering cooperation.

Delivering working software over comprehensive documentation

To manage dependencies, teams often use documentation. Each team documents the specification of what they will deliver and sends that to downstream teams. Once they have delivered their piece, they move on to something else. When the integration of all pieces finally occurs, defects are typically numerous. Even worse, teams who can resolve the defects are usually busy with something else and cannot resolve the problems immediately. This holds hostage the value of the working software, but documentation is completed successfully.

Agile Principles in Violation

Dependency Coordination puts direct strain on most of the Agile Principles from the Agile Manifesto¹.

Frequent, Valuable Working Software

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Working software is the primary measure of progress.

Dependency coordination and management delay value delivery. Delivering working software within a sprint becomes less likely. Coordination is never perfect. Teams or individuals on which you are dependent have usually moved on to something else when you need them to solve a problem. Due to competing priorities, dependencies are likely not working together with you in the same timeframe, which elongates the timeline. Measuring progress becomes difficult as all dependencies must be complete and integrated with no defects before recognizing progress.

Motivated, Trusted Teams Working In the Environment They Need

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

If a team operates in an environment that has dependencies, they do not have the optimal environment needed to get the job done. They don’t have control to complete the work. This frustrates the team and slows them down. Consequently, dependencies severely limit a team’s potential productivity regardless of their motivation level or the trust placed in them to get the job done.

Maximizing the Amount of Work Not Done

Simplicity — the art of maximizing the amount of work not done — is essential.

Dependencies destroy simplicity. When you lose control over your work, things become complicated. Even if you plan and manage your dependencies up front and improbably execute perfectly, the planning is extra work that you do not need if no dependency exists. Since executing the dependency plan perfectly is unlikely, the resulting defects and changes to the plan are also extra work items that work against simplicity.

Sustainable Pace Indefinitely

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

People or teams you are dependent on are never available when you need them. When they become available, you are usually busy. Customers are usually becoming impatient as timelines slip. This usually results in working in an unsustainable fashion to support the other team or catch up to deliver against a time constraint.

Effective Communication Through Face-to-face Conversation

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

In many cases, the people or teams on which you depend will not be co-located with you to enable face-to-face conversation. This lessens the quality of the communication and increases the probability of miscommunication and resultant problems.

Welcoming Changing Requirements

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Most dependency coordination efforts have a method of dealing with changing requirements — a scope change review process that ingests a change request, evaluates the priority, assesses the impact, and decides to include or reject the change. While this time-consuming and costly process might allow requirements to change, it can hardly be considered “welcoming,” and to the customer, it will not appear to harness change to their advantage.

Lean Wastes Observed With Dependencies

To round out the costly nature of dependency coordination, you will experience each of the seven Software Development Wastes² when coordinating and managing dependencies.

Partially Done Work

You will not attain valuable, working software until you complete all of the dependencies and integrate them into a working whole with no defects.

Extra Features / Over-production

Many will create extra software when satisfying dependencies. Future-proofing a piece of code to avoid future requests from the dependent team is tempting and often performed.

Extra Processing

The existence of a dependency results in extra planning, coordination, mock data, testing, documentation, defect fixing, change control boards, and other orchestration processes that you do not otherwise need.

Handoffs

Every dependency in the chain requires a hand-off and results in all of the miscommunication, relearning, and waste that comes with it.

Delays / Waiting

Things never go as planned — work takes longer than estimated, communication and shared understanding fail, other priorities emerge, or people in the dependency chain go on vacation. Deadlines slip. This translates to delays and waiting.

Task Switching

You hand off your part to the dependent team. You start working on something else. The dependent team has a problem and needs your help. This will interrupt your flow and result in costly context switching.

Defects

Due to integration being delayed until all dependencies are finished, defects are guaranteed. Plus, fixing the defects costs exponentially more due to the long length of time that has passed between introducing the defect and finding the defect.

Dependency Breaking Corrective Pattern:

The case is clear that dependency coordination is wasteful, time-consuming, and expensive. Given this, dependency breaking becomes a priority.

As you go into any situation with a dependency, keep in mind the three methods below for dependency breaking.

Figure A — Dependency-breaking Strategies

1) Do It Their Way

Develop the dependent item yourself. This can be hard for the dependency team or person to swallow if they keep tight control over their domain, but it can be the best solution for all if they are willing. It likely requires some upfront coaching from the dependency team or person on their standards and ongoing coaching from them with your team during your development. They will also need to help you set up for working in their environments before work begins. After you have successfully done this once, you now have this capability for similar situations in the future.

2) Do It Your Way

Develop your own mechanism, bypassing the dependency for now. Sure, this creates duplication and parallel efforts, but it can be the most expedient approach for decreasing the cost of delay given a dependency that is unwilling or unable to do the first approach above or if you want to avoid the delayed integration waste of step 3 below. When the dependent team or person is finally able to do the work for a more permanent solution, you can provide the mechanism you created as the ultimate specification (working software) of what we want to be delivered. Then, you can go to option 1 or 3 for delivering the longer-term solution.

3) Wait For It

When the dependency is done, then do your work. Don’t waste time trying to predict when the dependency team or person will finish your need. Start working when they are done…period. This does create unvalidated inventory until the point of your work integration with the finished dependency, which is not ideal, but it is better than wasteful coordination overhead that never seems to go as planned.

Conclusion

Dependencies are an unavoidable fact of software development. You can manage them or you can break them. Managing them is expensive and time-consuming. Breaking dependencies can give your team the control they need to deliver value expediently with less overhead and reduced frustration.

Stay tuned for future posts in the series on how to break dependencies at the task level, feature and story level, team level, and organizational level.

References

Agile Manifesto
Implementing Lean Software Development — From Concept to Cash, Mary and Tom Poppendieck — Sept 7, 2006

Originally published on Coach Lankford.

You can connect with Todd on LinkedIn.