chevron_left Back to insights

How to: Dependency management in Agile Transformation



Reading time

3 minutes


Jeroen Nollet


An important determinator of the efficiency of an Agile team is the number of dependencies it has before it can deliver functionality to its customer. In this blog on Dependency management in Agile Transformation, you find out what to do to increase the efficiency of your teams - and your organization.

About types of teams

A popular way to start an Agile transformation is to keep the current team composition as it is and to let them operate in the newly chosen way of working. But this adds a lot of complexity to your process.

There is often a difference between 'system' and 'development' teams.

If you don't change team compositions, you keep the dependencies between them and thus limit their delivery capabilities to the end user. 


Development teams

Development teams mainly focus on analysis, development, and test work. They analyze new features and implement and validate them before delivering them to the customer. 

System teams

The meaning of a system team can vary, but the common denominator is that development teams link to one (or more of them) in some way. Examples? Database administration, test automation, and deploy teams. But also the infamous Jira team I mentioned in my blog on uniform Agile Transformation. Even a release management team or a team responsible for a central component in the organization, and so on. 

Dependency management in Agile Transformation

Dependency removal

In large organizations, it will be nearly impossible to remove all dependencies. The environment is often too complex because of legal requirements, a syndicate, or other reasons. 

Nevertheless, you still benefit from actively searching on how to remove dependencies, even if it's only partly. It will add responsibilities to the development teams. That might feel unpleasant for some team members, but your workflow will be more efficient in the long run. There will be less waiting on other teams to deliver their work before you can ship a feature to the customer. 

A few examples

Dependency removal is a broad domain, so it is not easy to provide specific examples, but I will try to anyway:

  • Provide at least one person per team Administrator rights to your digital workflow tool (Jira, Azure DevOps, VersionOne, Rally, or other). This person could be part of a larger group of Administrators that frequently gather to share knowledge and insights.
  • Invest in automation. Automate your tests (unit tests, regression tests, API tests...), your deployment pipeline, or a database build.
  • Host communities of practice where employees with a common background (frontend developers, backend developers, Scrum Masters, Product Owners...) share their expertise and work on common goals. It enhances cross-company cooperation and sheds light on how other teams work.
  • Theoretically, the easiest solution would be to add the necessary experts to the team. But in large companies, this is often impossible because only a few experts are available. In the case of multiple dependencies, teams grow too large. An in-between solution could be to assign one expert per group of development teams that serves as a contact person. The advantage? Communication lines are short and efficient. In the long run, those experts can share their knowledge so teams can execute the daily work themselves. 

The examples mentioned above are short-sighted and will result after multiple steps in-between. Additionally, they require a lot of time, money, and effort before teams are mature enough to be less dependent on system teams.

In the long run, your dependencies on system teams will decrease.

Your development teams will get more predictable in their deliveries because of their higher autonomy. System teams can then focus again on the complex work in their expertise and have to worry less about day-to-day work. 

dependency reducing

Dependency management in Agile Transformation in a nutshell

Management should focus continuously on reducing dependencies. Short term, you will not see a lot of advantages. But look at it as a long-term investment. You invest time and material in processes and technologies that enable your teams to be more self-managing.

At first, it might feel like nothing changes, but after a while, a snowball effect occurs, and your investments will definitely pay back.

More insights on Agile Transformation? Read all about it in our Insights section. Know enough? Contact us!

about the author

Jeroen Nollet

Jeroen Nollet is Scrum Master and Agile Delivery Lead at The Value Hub. Certified as a Professional Scrum Master (level lll) and Professional Scrum Product Owner (level lll), he coaches teams in their Agile transformation challenges. By deeply examining team dynamics and designing practical solutions for specific problems, he helped out many customers in the scaling of their Agile workflow before. His technical background as a Java Developer turns out to be one of the biggest assets too in working with technical teams and issues.

Discover other insights