Why do organizations desire Agile?

Two of the most common items I hear organizations and executives identify as reasons for adopting Agile methods and practices are to increase their delivery speed and to become more predicable. When will X be done? There are valid financial reasons for these goals such as: when can we expect to book revenue for product X?

3 Things About Dependencies

In this article I will discuss 3 things about dependencies for groups larger than a single team. There are many techniques for resolving dependencies within a single team that I will address in a future post.

Structural Dependencies

These dependencies exist because of how the teams, the group of teams, or how the work is organized & defined. The very nature of team composition can create structural dependencies, such as the creation of a SaaS application with some teams that only work on the User Interface (UI). These would be known as “Component Teams”. They only create code for one component of the SaaS application, they would not write the application, API or database code.

Similarly, how the work is defined, in Features or User Stories, can expose structural dependencies. A typical example would be creating 3 separate features for a user outcome. One for the UI efforts, another for the application efforts and a 3rd feature for the database work. In my experience, this is most often the result of having component teams, but not always. Sometimes the work is broken down by application layer and then sequenced rather than working on the entire stack as a whole. This might be the case when the work balance isn’t allowed to self-level across teams (typically an indication of a push system rather than a pull system).

These dependencies might not always exist at any given moment, but because of the structure of the group or the work, they represent the potential for an item of work to require the efforts of multiple teams. I’m an old OO guy, in this case the structural decency is like an object Class.

Instantiated Dependencies

Instantiated dependencies arise when a potential dependency (structural dependency) becomes a reality for a particular piece of work. The structural dependency is now real, the work must flow between at least 2 teams to be completed.

To carry on the OO example from above, instantiated dependencies would be the creation of an object of type Structural Dependency.

Blockers, or Blocked Work

As an item of work flows through the system, and a team cannot proceed until another team does some other work, their work becomes blocked. They cannot proceed until someone else finishes dependent work. So they will typically add a “blocker” to their work.

Teams that are being honest and transparent will “keep the clock running” while an item is blocked. Other teams will “stop the clock” which can help hide the negative effects of being blocked. The clock should keep running, adding to Cycle and Lead times, while you are blocked. This will shine a light on the dependency as a problem to be resolved.

Dependencies Are Self-Inflicted Wounds

Many managers and executives don’t like to hear about self-inflicted wounds but structural dependencies are created as a result of past choices. Choices about team & group composition and structure. Choices about how work is represented in the system. And still other choices about how management is measured and rewarded. The mindset of Empire Building and the reluctance or resistance to change structure is one example.

Another unintentional consequence of organizing by specialty into component teams is uncovered by examining Conway’s Law. Conway’s Law hypothesizes that organizations design systems that mirror the communication structure. Or more loosely, systems are designed mirroring the HR hierarchy, as that’s most often the way information flows. This typically results in a highly componentized architecture of the systems and applications. It requires multiple teams of specialists, along organizational hierarchy, to create and maintain such systems. This, of course, results in many Structural Dependencies.


If one of your goals is to become more predictable, how can dependencies interfere? See the diagram below which illustrates the effects of handoffs and dependencies on predicable delivery. Even just one instantiated dependency between Teams A and B drops your on-time delivery probability to 25% (see the column under Team B). If it requires 4 teams to complete the work your on-time probably is a mere 6.25%. Hardly a predictable delivery system!

Bluntly stated – the more dependencies you have, the less likely you are to be predictable.

Dependencies have real financial impact on the organization.

Handoffs and dependencies can increase cycle time. As I mentioned above, if teams are honest and transparent about the work, they will keep the clock running while they are blocked. The cycle time of their effort will increase to include the amount of time they are blocked. As cycle times increase the time to value also increases, thus raising the Cost of Delay. All of these rising measures are counterproductive to the goal of increasing delivery speed for faster time to profit.

“If you measure anything, measure Cost of Delay” – Don Reinertsen

The negative effects of rising Lead & Cycle times and Cost of Delay increase at scale.

An Example

The below diagram is a situation that I experienced, though simplified to make it easier to understand.

A Program Level User Outcome was selected by ART (Agile Release Train) B for them to begin work. They initially decomposed that outcome into 2 Features, A and D, for Teams 1 & 2 respectively. Even though they knew Features E and F would later be needed, they didn’t create those Features right away. They knew the Lead Time clock would start ticking and they knew how they were being measured, namely Features Completed and Feature Lead Time.

As Feature A progressed in PI (Program Increment) N, Team 1 became blocked so feature B was created for a team in another ART (external dependency). That ART completed their work quickly and passed “control” back to Team 1 in ART B, unblocking them. Team 1 did a bit more work to close Feature A but then needed ART A expertise again so Feature C was created for the next PI.

As PI N+1 got started both ART A and Team 2 in ART B began working on and completing their Features. Once those were done Features E and F were created and worked in the next PIs. Finally, after 4 Program Increments, which is one year in calendar time, the Outcome was finally achieved.

You might think this was an issue, it took a year to complete one Outcome. But the teams, being measured by Features Completed and Feature Lead Time, looked really good on paper. Their metrics were in line with expectations. Even though none of the individual Features actually delivered any customer value!

What they did do though, along with all the dependencies, was to delay time to value. At scale, the problems and delays caused by dependencies are magnified.

Every Dependency Involves a Backlog

Besides the game playing identified above with the timing of feature creation to influence some metrics, a main point to understand is that every handoff involves a backlog, or a queue. Every dependency involves work in motion going to work at rest, waiting for prioritization and availability of the dependent team or person. That other person/team isn’t sitting idle just waiting for your work, they are likely already very busy working on other priority work, so your work goes into their backlog.

The new work waits until they have availability or something already prioritized and in flight needs to be stopped. These orchestration costs add up quickly and the delays can become real problems. Work sitting in a backlog is inventory, and all inventory has carrying costs. If we’re looking at this from a Systems Thinking perspective, all of the time the work is waiting for the dependent person/team to have availability is considered non-value add time. All of this contributes to delaying time to value.

Techniques To Reduce Dependencies

Hopefully by now I’ve gotten your attention and you are ready to do something about the Structural Dependencies in your area or organization. You are paying a price each and every time a structural dependency is instantiated in terms of time and money. Here are several high level categories of techniques to deal with dependencies. Contact Coach Dave for assistance in implementing them or digging deeper.

Communities of Practice (CoP)

A Community of Practice (CoP) is a group of people who share a common interest, skill or expertise. CoPs will typically meet regularly, have a defined purpose, and work to share information and grow as individuals and a group. 

Rather than having teams of specialists, requiring many teams to deliver an outcome, use a CoP per specialty and use Cross-Functional teams wherever possible to deliver value.

Cross-Functional, generalizing specialists

  • Team of teams level – Organize your team of teams to represent a product or value stream. Each team of teams should be capable of delivering a customer outcome end-to-end without reliance on teams in another team of teams. See the illustration above where work was required from multiple SAFe ARTs to deliver customer value.
  • Team level – teams should be fully cross-functional in that the team contains all of the knowledge and skills to deliver value. The team should not need to rely on the skills or expertise from anyone on another team. This is not to say that every person needs to be able to do every task. Rather that, collectively, the team can do all the tasks.
  • Individual level – individuals will most often have one or several skills where they have deep expertise (T or Pi Shaped). They should also, over time, develop other knowledge and skills to be able to help the team in ways other than their deepest expertise. When everyone can do a little more, you lower the risk of individuals becoming “bottlenecks” within the team.

Feature Teams

A Feature Team, what I often refer to as “Full Stack Teams”, have all of the skills and knowledge necessary to develop a product feature from soup-to-nuts, or from end-to-end.   They have the skills to do UI work, API work, database work, testing, operational skills to release the code and whatever else necessary.   Feature teams will rarely have dependencies on other teams to complete their work.  

One of the key concepts with Feature Teams is to think in terms of skills rather than official titles.  Rather than “we need 3 UI Developers, 2 QA Testers and 2 Business Analysts” think in terms of what skills are necessary to have, or grow quickly within the team, to deliver value end-to-end.   Then assemble those skills regardless of official HR titles.

Besides the dependency challenges of having Component Teams, another financial challenge you will encounter is that Component Teams never finish!  Component Teams will always find something to do to their component whether it delivers much customer value or not.  To not do this would be the end of the team, once the component was “good enough” the team would be disbanded.  What that means in your organization might be the end of employment – people will avoid this however possible.  Even if it’s to gold plate the heck out of a component that was “done” months ago.  Obviously teams doing low value work, while higher customer value work is in other teams’ backlogs, is detrimental to your bottom line.

A key point to ponder is:

That which is a Feature to a component team is a Task to a feature team – Ken Rubin

Team-to-team working agreements, could be temporary

When the same Structural Dependency becomes instantiated often, invest some time in creating team-to-team working agreements.  These agreements might include Lead Time notification such as “we need 8 weeks notice to have something ready”.    While some work is blocked for a team, perhaps also stand up a temporary “Scrum of Scrums” conversation to keep everyone updated on progress.

Reduce WIP

Reducing Work-In-Progress helps cure many ills and the negative effects of dependencies is also one of them.   Having a lower WIP implies you will have fewer instantiated dependencies “in-flight” at any given time.  This will lower orchestration costs by having fewer dependencies to manage at any given time.  People can spend that saved time delivering value.

Open Source Code Model

Requiring more trust than other techniques, adopting an open source code ownership model reduces the number of decencies and wait times.   Rather than handing-off work to another team, do the work yourself and then ask the other team to review the changes. 

Never let yourself be blocked – Henrik Kniberg

Wrapping Up

Using any one of the above methods in isolation likely won’t fix the dependency problems. You will probably need a combination of techniques. Select which ones might bring the biggest relief the soonest and experiment. As new teams or groups are set up a major goal should be minimizing the resulting Structured Dependencies.

There are many difficulties on the journey to increasing agility at the organizational level. There are also a number of challenges that are outside of the ability of the organization to control which is why agility is so important to the survival of the company. Some would call it “future proofing” – the ability to adapt at speed to remain viable and successful.

So it’s a blessing when you discover a systemic impediment to agility that you can control and improve upon from within. Look closely at what your teams and teams of teams are showing you. If you’re using SAFe look at the Program Boards from a different perspective. Not just the Objectives and Features, but the red yarn. It’s there for a purpose, not just to show the dependencies but to scream at you “DO SOMETHING ABOUT THIS!”

The choice is yours – stop shooting yourself in the foot and increase your agility, predictability and lower your Cost of Delay. Or maintain the status quo and expect the same results.

Until next time!

(Visited 59 times, 1 visits today)

Leave A Comment

Your email address will not be published. Required fields are marked *