Ideally, we have teams that can get end-to-end solutions to the user relatively autonomously. This enables them to deliver quickly, and since they work in parallel with the other teams, the organization can easily scale up if it wants to increase the output. Such teams are often called feature or product teams. Feature/product teams are multifunctional teams that deliver small but complete customer-centric solutions. To achieve this, each team works across all components and disciplines. This means that they simultaneously work on the front-end, middleware and back-end system. The team also does all the analysis, programming, and testing.

In most organizations I work with, this is a pipe dream. The development teams cannot operate autonomously—they rely on other teams to finish the end-to-end solution. Before the launch, other teams must complete their changes as well. For example, we often see component teams—where one team makes all the front-end modifications while another team takes care of all the back-end changes. We also see functional teams, where the business analysts make the design, programmers build the software, and a dedicated test team works on the code made by the programmers. Although working with component or functional teams requires extra coordination, the majority of organizations I know work with teams that cannot deliver an end-to-end solution. This creates inter-team dependencies that need to be managed.

Dependencies have a great impact on the delivery of the organization. They can result in delays, more expensive solutions, or can sometimes cause the product not to see operational daylight at all. Let’s have a look at five types of dependencies, their impact, and how to address them.

1. Chain/Technical Dependencies

The first dependency type people think of when working with component teams is the chain or technical dependency. To deliver an end-to-end solution that has value for the user, the development team needs other teams to complete their changes as well. These typically are other systems in the chain or preceding/next steps in the customer journey.

For example: A travel organization is building a reservation system. The booking engine allows selecting a flight, entering the customer details and making the payment. The team building the front-end works closely with the team that maintains the customer database. When a new feature is being launched, the coupling with the payment module causes a delay. The status of the payment needs to be set to “completed” before the booking confirmation is sent. Unfortunately, the payment team didn’t complete the item yet.

2. Stack Dependencies

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.

For example: In a government organization, user requests need to be checked against the applicable rules. Since the rules are changing regularly, the system architecture uses a rule engine that checks the requests being sent from the workflow system against the regulations and returns an approval or suggestion. This design enables the organization to update the rules without having to change the workflow. Since the two components are delivered by different teams, dependencies are introduced. Planning and technical alignment are needed to keep the systems in sync and the end-to-end process working.

One check in the customer journey is whether the user is of age. The rule engine checks whether the age is above 18. When integrating the two systems, it becomes clear that the engine expects an age while the workflow system has just been adapted to send the user’s birthdate. “I checked with the other team,” Susan mentions during the stand-up. “The good news is, that they do have a user story on the backlog to adapt it. But before you start cheering—they don’t think the item will be included in the next two iterations.”

These stack dependencies introduce a risk of defects and rework. They require attention if the dependency requires the items to be released as a package. We don’t want to have to rebuild the code when one of the items needs to be withdrawn from the release.

3. Shared People Dependencies

Shared people dependencies arise when teams rely on people that are not fully dedicated to the team. This occurs, for example, when specialist knowledge about security, usability, performance, past decisions, or undocumented features lies with a small group of developers. This also applies to specialists like security, usability, and performance experts.

A continuous flow of value output also hinges on reviews done by stakeholders, approval from the business, 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.

For example: A team is planning their next sprint. One of the items on the backlog depends on a specific stakeholder to give her OK on the change. The team has checked whether the internal developers are available but failed to check the availability of this stakeholder. The stakeholder is not available in the coming sprint to approve the change. “How are we getting this one into production?” one of the developers asks, “when she is on vacation?” The team agrees to drop the item and work on an item that can make it to production this sprint. “When the stakeholder returns, we can always add the item to the backlog.”

4. Shared Resources Dependencies

Another type of dependency surfaces when resources like licenses and environments 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. A solution is to have enough licenses and multiple environments—but they come at a cost. Containers and virtualization may offer a flexible solution, but not every environment can be put in a container, especially when there are physical hardware components or different suppliers involved. Think of entry portals that are part of the ticket system of a subway station or a usability lab that needs to be hired commercially.

For example: Many organizations depend on supplier releases. To continue development, a new release from an external supplier is required, such as a new version of iOS when doing mobile development, service updates on the database system, or using a test execution tool. We might need new features from the platform to become available before we can include them in our release. A housing corporation I worked with also had that problem. When they wanted to improve their customer portal, they had to wait for the supplier to add it to their platform release.

5. Shared Codebase Dependencies

When multiple teams are working on the same code, this might lead to dependencies as well.

For example: Recently, I facilitated a session where two teams were expressing their frustration to each other. A developer in one team had broken the tested code made by the other team. And when giving a demo to the stakeholders, they discovered that changes made weren’t included in the used build. The frustrations on both sides are understandable. In the end, both teams made working agreements and created a dependencies sheet in Excel. Filling in who’s working on what code and the impact this has required discipline but solved the immediate inter-team problems.

An Excel sheet seems a little basic, but it can get teams to collaborate again. A better solution can be to move to CI/CD, have good configuration management in place that enables frequent integration, and run an automated integration test. However, setting up such a pipeline with automated tests requires time, effort, and knowledge. Teams often lack the time and hands-on knowledge to implement these kinds of improvements.

Dealing with Dependencies

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. I think that is great. However, to avoid too much time being lost on alignment, it is good to take dependencies into account not only during preparation and planning but also while refining an item.

Figure 1

To get a good feel for the dependencies, we can include extra information in the feature or backlog item template. This can look like the table in the illustration.

During planning 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. We can do this during Sprint-backlog refinement, but preferably as soon as possible, e.g. already during the first refinement sessions. This will reduce surprises, create better awareness, and help boost value delivery.