Slow Product Development? Dependencies are the Cause

The more you try to deliver in parallel the slower delivery gets.

This is often seen as the price you pay for scale. Larger companies just move slower than smaller companies. But it doesn’t have to be that way. The issue isn’t scale; it’s dependencies.

There are four core dependencies that can occur in parallel software deliveries:

1. Scope: different projects may be building features that conflict with each other

2. People: different skill sets are required, meaning key individuals might be needed across multiple deliveries.

3. Code: even if the features do not overlap, teams will often need to modify the same code, leading to merge conflicts.

4. Environments: while multiple projects are being delivered in parallel, there is usually only one production server, so all projects must navigate the “path to production”.

Dependency Problems Are Not New

Companies have been trying to minimise the impact of dependencies for decades. Let’s review some common strategies and the challenges they face.

Taming Scope Dependencies

Planning deliveries up-front helps identify and mitigate the impact of scope dependencies. Business case sign-offs, increment planning, and dependency mapping are examples of this. Projects and initiatives are often staggered to avoid the risk of teams working on conflicting features simultaneously.

However, there are significant downsides:

1. Time and Effort: It takes considerable effort to map all scope changes across multiple parallel initiatives.

2. Misaligned Priorities: Lower-priority items may be prioritised to avoid conflicts, slowing down high-priority work.

3. Constant Change: The real world often disrupts even the most detailed plans. Unforeseen challenges or delays force cascading changes across multiple teams, adding complexity, planning overhead, and delays.

To manage this, companies often hire project managers, program managers, scrum masters, or chief product owners, which introduces additional overhead and cost.

Taming People Dependencies

People dependencies are often managed in the same way as scope dependencies using upfront planning to identify demand and staggering initiatives based on availability.

This approach carries the same issues as managing scope dependencies but adds the complexity of coordinating both scope and people, making the process more expensive and time-consuming.

Taming Code Dependencies

One common approach to managing code dependencies is using the Git Flow methodology. This involves teams working on separate branches (copies) of the code base. While this avoids conflicts in the short term, it introduces the issue of merge conflicts when branches are reintegrated.

Reintegrating branches often leads to Merge Hell. Developers need to manually review each conflict which is time-consuming and error-prone, particularly for long-lived branches. Furthermore, multiple branches complicate continuous integration (CI), as automated tests must verify multiple versions of the code rather than a unified product.

Taming Environment Dependencies

Environment dependencies have been mitigated by the rise of DevOps. Automated pipelines can now test, package, and deploy new product increments. However, while this has improved speed, bugs that surface during this phase can be hard to resolve. Since anyone can push to production at any time, by the time a bug is detected, multiple teams may have already pushed additional changes, making root cause analysis challenging.

Many companies limit production pushes to scheduled “release windows,” often referred to as a release train. The downside? This caps the number of releases and introduces new roles, such as the Release Train Engineer, further increasing overhead.

Our Mitigations are Not Working

Despite all these strategies, releasing software continues to take longer and cost more. That’s because we’re approaching the problem the wrong way. Instead of “managing” dependencies, which increase exponentially with the number of parallel releases, we need to remove them.

We’ve long known that smaller teams outperform larger teams due to Brooks’ Law—communication lines grow exponentially as team size increases. We need a similar concept for dependencies: as the number of parallel deliveries increases, so too does the complexity of managing them.

Unfortunately we can’t fix the dependency problem in the same way as we mitigate the impact of large team sizes. While the solution for team size is to reduce the number of team members, demand for new products and features already far exceeds supply so reducing the number of deliveries is not an option.

Instead we need to take a different approach. We know that adding process and managers does not work. Instead of focusing on managing dependencies, we must focus on removing them. In fact, this is the vision statement that underpins the ZeroBlockers framework.

Removing Dependencies

Removing dependencies is not easy - otherwise we would already have done it. But it is possible.

Scope

Switching to a product model—shifting from project-based teams to product teams—eliminates scope overlap. In a product team structure, each team owns a specific part of the product, or value stream, ensuring no scope conflicts.

Code

Each value stream team should own its own code base, essentially making each team a mini-product. Teams can interact via APIs, similar to how they would work with external third-party integrations.

People

Long-lived product teams with all necessary skills onboard prevent delays due to key personnel being spread across multiple projects.

Environments

Because each team owns its own code base, they have their own path to production. While this requires some initial work to integrate the separate code bases, automation via CI pipelines can handle this.

Conclusion: A Journey Towards Independence

As we scale and increase parallel deliveries, the exponential growth of dependencies can become overwhelming. Adding more processes and managers has only slowed down delivery and raised costs.

The solution is to stop managing dependencies and start removing them. This approach requires a commitment to rethinking traditional methods, but the rewards—increased productivity, faster delivery, and reduced conflicts—are worth the effort.