Dealing with dependencies

There’s a lot of talk on dependencies. When developing solutions, whether they’re software, hardware or organizational, it’s the dependencies that make things complicated and slow down the delivery. They can result in delays, more expensive solutions or sometimes cause the product not to see operational daylight at all.

Ideally, we have teams that can get end-to-end solutions to the user relatively autonomously. This enables them to deliver fast and since they work in parallel with the other teams, the organization can easily scale up if it wants to increase the output.

In most organizations I work with, this is a pipe dream. The development teams can’t operate autonomously; they rely on other teams to finish the end-to-end solution. Before the launch, other teams have to complete their changes as well. These typically impact other systems in the chain or preceding/next steps in the customer journey. These chain or technical dependencies create overhead as they require extra meetings and alignment, and they delay feature completion.

Not all technical dependencies are in line with the customer journey. Frequently, items rely on changes made elsewhere in the system. I call these stack dependencies. Examples are database adaptations that are necessary to support new functionality or an adaptation of the validation rules to support a new type of data entry. Stack dependencies often require items to be released as a package.

Shared resources

There are more types of dependencies. Shared people dependencies arise when teams rely on people that aren’t fully dedicated to the team. This occurs, for example, when specialist knowledge about security, usability or performance, or knowledge about past decisions and undocumented features lies with a small group of developers. A continuous flow of value output also hinges on reviews done by stakeholders, approval from the business and users contributing to user acceptance tests and giving input on requirements. Although a logical thing to do, the availability of these people is often not checked, resulting in delays and backlog items flowing over to the next iteration.

Another type of dependency surfaces when resources like environments and licenses are shared. When multiple teams are using the same resources and depend on a common test environment or tool to complete their work, this often results in complex planning situations. Especially when one of the teams is delayed, it can put pressure on the planning and other teams.

When multiple teams are working on the same code, this might lead to dependencies as well. Recently, I facilitated a session where two teams were expressing their frustration to each other. A developer in one team had broken code that had been created and tested by the other team. And when giving a demo to the stakeholders, they discovered that changes made weren’t included in the build that was used. The frustrations on both sides are understandable. Good version management and continuous integration can solve these dependencies, but not every organization has mastered this yet.

Good feel

To deal with dependencies, we need to make them transparent. Development practices like CI/CD can do that on a technical level. Failed tests provide a fast feedback loop indicating that some dependencies have broken the system. In many organizations, scrum-of-scrums and developer sync meetings are being held to discuss dependencies during the iteration. However, to avoid too much time being lost on alignment, it’s good to take dependencies into account not only during preparation and planning but also while refining an item.

To get a good feel for the dependencies, we can include extra information in the feature template. During refinement, we assess what type of dependencies (if any) are dominant and add an explanation of the impact and risk or suggest how to eliminate the dependency. This will reduce surprises, create better awareness and help boost value delivery.