Black and white photo of a group of teens in 1978 pulling on one side of the rope in tug of wars.

External dependencies cause:

  1. Communication overhead
  2. Risk of conflicting interests
  3. Temporal dependencies and scheduling problems

(Interruptions from auditing, or bugs found by external quality assurance, is a version of temporal dependencies.)

This consumes resources that could’ve created value.

As soon as the software organization grows enough for the developers to split into more than one team, the dependencies will change. In the worst case both teams depend on everything the old team depended on, and each other. Managing dependencies more important in bigger companies (due to math). Kent Beck has a great text on what you can do to deal with dependencies from within an existing team. The suggestions below require more influence over the organization. The goal is to create working software with as few dependencies as possible for each team, while maintaining a reasonable team size. The book Team Topologies covers much more on how to organize teams, so I include their names for different teams along my own.

Including the stakeholder in the team

This is done in DevOps. When running the code is included in the responsibilities for the team, operations is no longer a stakeholder. The same can be done with product, security and user experience. This is one of the reasons to have the customer be part of the team in XP. A cross functional team gathers all expertise in one place. The main focus is solving the business problem as well as possible. This improves all three listed problems with dependencies, since collaboration is moved to within the team.

Intent centered software teams — slicing teams along intent

Organize teams around their goal (user path or feature) instead of what technology they use. This also requires cross functional teams. It is easier for the code to adhere to the single responsibility principle when the team has only one goal. In Team Topologies the “Stream aligned team” is clearly intent centered. “Subsystem teams” and “platform teams” can also fit the description, if the other teams are seen as their customers. Solving the scheduling aspect of the dependencies relies on that the stream aligned teams can move forward independently of the subsystem and platform teams. (Platform teams are very different from a backend team, that still has to implement changes for each feature in the frontend.)

One way to see it is that the business logic is created by stream aligned teams. The technical advantage can be created as a subsystem or platform, used to improve the work of other teams as it gets available.

Service teams — from push to pull

If the overhead from having specialists in each team gets too big, you can have service teams. In Team topologies those are “Enabling teams”. This flips the direction of dependency between teams. If the legal team is there to control, it is a stakeholder for the software team. On the other hand, if the software teams take full responsibility for the legality of their code, the legal team can be there to serve them. The legal team then has the software teams as their stakeholder. It can still create delays, but the control and the responsibility is with the development team. Legal advice is pulled from the legal team instead of pushed to the development team. This can be used for other areas as well. Service teams still have to manage their time, but they should at least not have to explain why their work is needed. So the conflict in interests is solved.

Universal design — including diversity in the norm

The core in universal design is to move away from the able bodied user as a norm. People with disabilities are not a new kind of user, they are a part of the general user. We design for different screen sizes, without having stories like “as an iPad user I want to be able to buy a ticket”. The same way we can simply make accessibility a part of how we work. This is easier with a diverse team. Universal design can also be expanded to include other marginalized groups. I don’t think that “as an african american I want to be able to use face recognition” should (need to) be its own story. It is what we want to achieve that differentiates users, not the circumstances we are (currently) in.

Bonus: Cutting dependencies within a team

Read my posts on working in an ensemble! This deals with all the listed problems with dependencies, but between individuals within the team.


Comment on the blog!

Create a comment by emailing me.
I will then add the comment to the post.

Open an email to start writing.

Related texts

A coach talking to a team of very enthusiastic young kids, many with their hands raised.

Three reasons to get a Samman coach

Water colours in a box

IT-stress, part 2 — change