Dependencies kill Agility
We recently completed our latest PI (Program Increment) and our teams are now practically one year into our 100% Agile ways of working.
Reflecting on our latest PI, I got thinking about our single biggest impediment, the dreaded ‘Dependencies’.
Typically, in Agile, and especially Scrum, we work under the pretence that we have autonomous teams. This in my opinion means; teams have everything and everyone needed to deliver a piece of work.
The work itself can be broken down into 4 types of work or if you have come across the Flow Framework, you’ll recognise the work better as the 4 flow items;
1. Creating a feature
2. Fixing a bug/defect
3. Managing Tech Debt
4. Managing risk
Which can be measured in some shape of form in business value.
But the reality is that if you are working at scale, in a large enterprise, with multiple businesses/portfolios with different business strategies or priorities, with multi executive stakeholders with a single, large IT dept then that’s hard to do!
So hard that we can struggle sometimes to get our heads around it.
When a team doesn’t have everything, and everyone needed to deliver it’s because dependencies exist, and these dependencies can come in various forms.
When doing scrum, the irony is that scrum assumes you have no dependencies. In a large enterprise, we’re not only talking about dependencies between the team and external entities but also between teams that need each in the form of inbound (another team needs something from our team to deliver) and outbound (we need something from another team to deliver) dependencies to deliver.
These kinds of dependencies don’t just go away. We can’t simply wave a magic wand and magically make them go away or pretend they don’t exist. They are real, and they are in our way.
As long as we have them — Real Agility isn’t possible.
So we have two options, and how we choose to deal with our dependencies and how we decide to deal with them is fundamental to Agile’s effectiveness in our organization.
We have to either eliminate dependencies or manage them.
Arnaud van Rietschoten tackled it. At the end we are Technology and need to provide technology answers. Last century technologies are not really agile-oriented
Andy, if 1) your low-level design is done in the teams, 2) you have infrastructure self service and 3) all testing happens in the team the dependencies should be minimal..... Something must be wrong in either three for you to raise this.... The issue is not agile the issue must be your organisational design or foundational readiness.....