Dependencies
Spend any time in companies building products with multiple teams and you feel the pain of coordinating those teams. I see day in and day out the uncertainty that dependencies add to forecasting work through those development networks. It makes little sense to me that we strive and argue about estimating the individual pieces of work that typically take a few days of hands-on time, and totally ignore the weeks and months of idle time in our processes where we struggle to collectively combine that work into a delivered product.
I see these problems in Agile’s doctrine regarding dependencies.
“Just cross-train teams with all the skills they need to deliver in isolation”
This quote assumes that the only type of dependency is based on a skillset that lives in another team. Something a good re-org and skill-sharing endeavor will fix. This isn’t wise. Today’s software products are assembled using many technologies. Even simple websites nowadays require HTML, CSS, JavaScript (and Typescript to make them manageable), and dozens of third-party libraries, not to mention the AWS or Azure infrastructure, logging, and analytics frameworks - shall I go on? OK, I will - training and building customer support, billing, legal for the privacy statements, translators for the content in multiple languages. You get the idea. You can’t and shouldn’t look to avoid dependencies in such a complex environment. But you shouldn’t have dependencies where they can be avoided either. I’d like to see “Cross-train the teams on the skills they need for EVERY feature that the team will build, and make sure we manage the rest of the dependencies better.”
Do
Cross-train team members on the skills they need for EVERY (or almost every) typical job that team does day to day (cross-skill the nurses)
Manage dependencies better for “sometimes we need” skills so as NOT to bloat the team with one-off work where expertise matters (keep the brain surgeons compartmented)
Read and share Team Topologies and Dynamic Reteaming
“Identify Dependencies During Release Planning (using red string)”
A common scaling framework that is best known for large diagrams and expensive certification training, promotes connecting work using red string where there is a hand-off dependency (see the picture above). Even if you spent considerable time identifying these dependencies - NOW WHAT! I guess they put everyone on the same page as to the hand-offs, but this does nothing about reducing them, and ignores a whole set of dependency types, like "we need something”, “we need to learn”, and “if we do this, we also need to” dependencies. If you are going to laboriously identify this narrow definition of construction-order dependency then I suggest doing the following.
Do
Consider construction-order dependencies, but challenge the teams’ to reduce hand-off times of partially deliverable work
Make sure work is prioritized in a visible way so that hand-offs are started in a value-enhancing (cost of delay reducing) order - NOT all red strings are equal, make some pink!
Also, probe for other dependency types, see below.
“Don’t have dependencies at all”
You need them. They change, so the best you can do is reduce the ones you had yesterday…. And, compartmenting some skills gives you economy of scale, a higher expertise level where failure must be avoided, and reliability (not everyone should have access to production servers and administrative passwords!).
How Do I Approach and Teach Dependencies?
Here are a few snapshots of my approach -
There are four types of dependencies, not one, and you need to consider all of them in some way -
Things we need others to do before we (the typical one Agile manages)
Things we need to learn before we start/do
Things we need to have before we start/do
Things we will also need to do if we start/do this (update training, android & iOS, etc)
Dependencies leave historical evidence of frequency and impact as “Blockers”
By capturing the Frequency and Impact (days lost) of historical blockers we can quantitatively assess which blockers (tomorrow’s dependencies) should be fixed.
Clear prioritization of work is necessary for other teams to start the right work
That our goal is to create a process that allows the work to be started in the order we NEED
Sometimes a little more communication at the right time is all that is necessary to halve the pain.
I stress that it’s a continual journey, not a one-and-done reorg that will improve flow in scaled organizations the most. There are no easy fixes, but there are quick wins if you know where to look.
I run instructor-led private workshops on dependency management, and also have self-paced training on this topic, reach out and let’s chat.
What are some actionable things I can do right now?
Start tracking blockers. Cluster and count the days lost due to some common cause, for example, “firewall changes needed,” or “missing images/text”
Start asking questions about the four types of blockers during planning. For example, “Do we know how to do this yet?” “Do we need a new VM for testing?” “If we do this for Android, do we also need to do this for iOS?”
Create touchpoints between teams that commonly need help from each other; make sure they share prioritization of the epic or feature being delivered so the right work gets unblocked first.
