Stop Managing Dependencies!
Dependencies in Software Development have been an issue since decades and lots of practices have been built to “manage” them, creating an environment that becomes more complicated with longer time-to-market times as dependencies grow (or the product/solution grows).
This is creating an illusion and no dependency management is alwys the only answer! Coordination to remove dependencies is usually a more sustainable outcome with less management.
The difference between managing and coordinating dependencies in IT
What’s the difference between managing and coordinating? Let me give you some idea of what I see differently.
We accept that dependencies are there and will always be there
We see dependencies as improvement opportunities
Skill dependencies are managed through “resource management” and teams are build around creative work which is not solving the dependency but is taking it as a constraint.
Skill dependencies are managed through “education” and work is given to creative teams who will solve the dependency out of necessity.
Technical dependencies are managed through release managers, integration teams, project managers, quality assurance, acceptance testing… “people” (error prone by default)
Technical dependencies are managed through automation and fast feedback mechanisms
Main focus is to visualize and follow up on dependencies
Main focus is to adjust the system to remove dependencies
There is no incentive to adjust the root causes of having dependencies, dependencies stay.
As there is no way to manage the only way is to deal with it in a way that managing is not needed (anymore)
Full solution/product focus for people in the system is almost excluded, and as such removes the understanding for whom they are building things and why, lowering motivation… as a consequence.
Full solution/product focus keeping the teams close to the customers and motivating to keep giving the best.
Situations with dependencies create:
- Accountability of one or multiple people put on a certain piece of the solution/product. (Technical)
- Skill gap in a team to deal with a piece of development to do. (Skill)
- External component from external vendor where there is no way for the organization to change its internal workings (Buy)
Stop managing dependencies and do it today in favour of tomorrow
Accountability on a piece of the solution create dependencies
Accountability is an illusion that will lead you to the dark side and has been explained in an article around efficiency, read it here. Remove accountability on a piece of the solution/product and transfer it to the whole solution/product for all teams as a team.
Remove individual accountabilities and move to teamwork, collaboration.
Yeah, but the other teams will break the workings of this piece of the puzzle we were previously accountable for!
First of all, you can not blame the others for breaking things they do not know they are breaking. Meaning that whenever you feel the need to blame somebody for breaking what you did, you should think how can I make sure others immediately know they broke something? Automated testing on different levels for example – unit, integration, smoke, performance... Invest in C.I. when this is an issue instead of investing in dependency management, solve the root cause and do not put a bandage on an open wound.
Yeah, great, but what when things go wrong in production?
Providing all teams are accountable for the whole, it makes things easier doesn’t it? No need to try to figure out in which piece of the solution/product things go wrong in order to be able to assign it to some team. Every team is accountable for the whole we can just pass the issue to all the teams where the team that feels most suited to fix things or has immediate time to fix things can take it up and arrange a solution (self-organization).
Yeah, ok, but not every team can do everything?
It is indeed impossible for every small team to be able to do everything in a huge solution/product, teams will organically specialize in certain parts and that’s a good thing. That’s why we said the teams will self-organize around the issue and the one having the time & skills will take it up. If the skills are an issue then we come to the next part of this article.
Skill gaps create dependencies
The high complexity of things like a huge solution/product will require a high diversity of specialized skills within the organization to build something successful. Of course we are aware about T-shaped or even PI-shaped profiles but this has its limits.
Sometimes work will come to a team that requires skills the team does not have or where the team has a dependency to another team (inside or outside the same organization). Instead of managing that dependency and keep the skills where they were before we coordinate around the imaginary dependency and look for ways to get the skills from one team into the other so that there is no dependency to manage anymore.
In LeSS this is done using the travellers, if this is applied to an external organization we could say we hire-and-fire an expert to acquire skills in the team. This way we keep domain knowledge inside the team and optimize the TCO of our solution/product. Why would we want this? Easy, just answer this question for yourself: “What is the reason people say it will take about 6 months to get a junior team member operational/productive?" Is it about Java knowledge? .NET knowledge? Any other technical component knowledge? Not really, most (not to say always) it is about understanding how the technology, component is used within the solution/product and by extension the market needs/workings the organization is active in. Which helpes us to conclude that it is better to setup an organization optimised to contain/maintain domain knowledge, not expert technical/component knowledge.
The fun part of dealing with the skill gap instead of managing the dependency is that you teach your organization to deal with any kind of new technology that is coming up in the future and as such become more resilient and prepared to survive the fast pace of innovation these days.
Another way this skill gap deficiency is becoming a problem is when the organization does not split their work appropriately but this is a topic for another time. For now we would recommend to have a look at Lean Startup or Design Thinking techniques as well as Impact Mapping or even our own Splitting Card Deck.
Yeah great, we do have a very good C.I., we moved all accountabilities to the highest level possible and we have all skills needed and our organization knows how to get those transferred to each other but we have to deal with parts of the solution/product that are bought from an external vendor where we can not change its code/core.
External vendors – bought components create dependencies
It is good practice within organization to focus on their core activities (see business model canvas) and find partners or external vendors to “buy” the other parts of their solution/product. But this creates a dependency doesn’t it? Yes it does and seemingly one we can not tackle at the root cause.
So, what can we do?
There are several options, the one slightly better than the other but for you to decide.
- We make sure we can isolate the external part and build a layer/interface around it that we can adjust as needed. This way we can override some functionality (in my past also wrote C++ code on top of windows libraries to avoid certain unwanted behavior from the OS, so even core items you can mask) or we can replace the bought item with another very rapidly and easily.
- We get into a contract with the external vendor where we are allowed to contribute to their deliverable and as such can commit code where needed and as such remove dependencies while expanding/creating our own solution/product. This will require a tight collaboration that makes it a bit more difficult but definitely worth a try, when this is put in practice you truly get into a win-win collaboration.
- In some cases we have been in a situation where the organization just bought the external vendor to acquire true business agility and optimized internal workflows.
Next to above mentioned situations we also have to deal with a lot of other, imaginary dependencies or dependencies created because of the way the organization is producing value to their customers.
Example: We are an insurance company and sell different insurances, life, fire, car… where each will have its own strategy to go to market, each have their own programs to execute the strategy and each program has multitude of projects to deliver upon. This kind of setup will introduce dependencies between projects, programs as well as strategic themes. - Why not consider having 1 strategy for insurance including all different things? - Why not applying lean startup, impact mapping to unleash experiments to your market to validate your strategy/idea’s/assumptions? - Why wouldn’t we have a single backlog of things we want to unleash? - Why not using an empirical approach to continue building your business instead of trying to be predictive? - Wouldn’t that remove those dependencies as well?
Conclusion on how to deal with dependencies
As you can see any kind of dependency should not be managed but treated as an opportunity to improve the system.
Of course this is not always easy and there is not always an immediate solution available but as soon as you setup a system to manage dependencies instead of coordinating around them the intention to improve and remove them goes away.
Want to improve? Want to really become customer centric? Want to become fit for the future? Stop managing and start coordinating dependencies. Avoid setting up a process, system to manage dependencies; Try to create a process, system that coordinates around dependencies.
PS: We do like challenges at Co-Learning and if you have dependencies you cannot handle but want to handle instead of managing?
Give us a shout; we’ll join you and your team to get this done.
PPS: you might also want to check out the following to get inspiration how to go from managing to coordinating around dependencies:
- The complete LeSS website as a lot of things like PSPI, C.I., Done, Descaling Organization, Case Studies will provide lots of insights on how to go from manage to coordinate.
- See how Scrum.Org deals with dependencies using the Nexus framework, in particularly the Nexus Integration Team… (might be an in-between situation and good practice to move fast forward)
- Or even how SAFe manage dependencies on different levels through solution architect, systems team, devops, release management, release train engineer, systems architect/engineer… (might be an in-between situation to get things moving slowly)
No preferences and in the end all depends on context.