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.
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 mainly focus on analysis, development, and test work. They analyze new features and implement and validate them before delivering them to the customer.
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.
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.
Dependency removal is a broad domain, so it is not easy to provide specific examples, but I will try to anyway:
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.
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.