Dependencies

In today’s episode of Let’s Expose Common Assumptions, we’re going to be discussing dependencies.

Conversations around dependencies in technology organisations often rub me the wrong way. Experts talk about exposing or managing dependencies, as if complex architectures are inevitable. The various Agile at Scale frameworks are often built on this assumption. As if successfully identified and managed dependencies is the end state, at which point everything which can be done, has been done. “Now that we can manage our dependencies, we’re going as fast as we can; this is a good as it gets.”

Dependencies are an organisational smell. They’re the result of business debt, or incorrect organisational design. It is entirely possible, with what we know about software development, to build massive systems which carry minimal dependencies, where the few dependencies that do exist are managed transparently. It’s hard. And it follows very different models than most organisations understand. But it’s possible.

I can help you understand your dependencies. We can visualise them, expose them, talk about them, and order work around them. But that’s just step 1. Step 2 is reducing and removing dependencies. Reshaping teams, and architectures, such that a single team of people can do their entire job, from design to support. It won’t be easy, but I think it’s better, in the end.