We’re going on record to tell you that dependencies will be your biggest challenge along your Agile Transformation journey. Dependencies reach far beyond the delivery teams and have most likely taken root in all aspects of the business.
Your organization probably looks something like the picture below.
When you try to apply Agile in an organization that looks like this, it creates a lot of cognitive dissonance for the people in the organization because these dependencies are incongruent with what Agile teaches.
So, people resist the change, and you start breaking Agile to fit your current system. Leadership isn’t getting the desired results they want, so they step in to take back the reins and begin to micromanage the teams, and now the teams don’t have what they want either.
It’s a vicious cycle.
Overcoming Dependencies
When it comes to dependencies, you only have two choices. You break them, or you manage them. But you don’t get to pretend like they don’t exist or assume that Scrum will identify them and the teams will be able to self-organize dependencies away.
Many dependencies are self-inflicted. They get introduced by how you architect the product. They get introduced by how you staff teams. They get introduced by how you bring work into the organization, by how you create roadmaps, and by how you sell changes to your customers.
That’s good news, though.
Because dependencies are primarily self-inflicted, most of them can be broken with enough time, money, and attention.
Even if the dependencies can’t be broken from your point of view or your role, someone in the organization can break them. We just have to find those people and let them decide if it’s less expensive to break the dependencies or continue managing them.
Dependencies won’t prevent you from doing Agile practices but will prevent you from reaping the benefits. So, again, you can choose to manage the dependencies or break them. But you can’t pretend they aren’t real and aren’t limiting your Agility.
