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, has 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. In fact, 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 Manifesto1 as described below.
Individuals and interactions over process and tools
Dependency management and coordination adds 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 align 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 control of the team with dependencies.
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, scope is defined, and 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, they stand in the way of team collaboration. Teams form boundaries, hindering cooperation.
Delivering working software over comprehensive documentation
In order 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 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 Manifesto1.
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 delays 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 time period, 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 the 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 Wastes2 when coordinating and managing dependencies.
Partially Done Work
You will not attain valuable, working software until completing all of the dependencies, integrated 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 fails, 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.
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 setup 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 delivered. Then, you can go to option 1 or 3 for delivering on 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 a 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.
转：https://coachlankford.com/2018/11/11/gain-control-by-breaking-dependencies-an-introduction/
