Stop being dependent on dependencies
How to break free of your dependencies when working on products at scale.
TLDR:
Handling dependencies is key to being successful when developing products. I look at where dependencies emerge from, the common strategies to tackle them, why standard methods are unsuccessful and what you might do to release your teams to be agile and deliver better products faster. In short, how to break your dependence on dependencies for organisations building products.
The most effective strategy is to count and report on dependencies and then take action to reduce this number. Split work into smaller, less dependent deliverables, make teams and individuals multi-skilled and build teams around customer value journeys where all the knowledge, skills and tools needed are self-contained.
Dependencies:
Tasks that require input from other tasks to be completed, or Activities that cannot start until a previous action is done.
Where do dependencies come from?
Dependencies are inevitable. You’ll get dependencies if you have more than one person working on something. Dependencies come from time, place, or resource. It could be a limit on how many changes you can commit in a period or a clash over the timing of a deliverable. It could be a need to work on the same piece of code. In any event, they are a fact of life.
As companies scale up from one developer to several and then to multiple teams, there is a natural growth of dependencies.
What dependencies do to products
Dependencies are an existential threat to delivering great products. While dependencies force teams to collaborate (no bad thing), they make it hard to iterate and learn quickly: an anti-pattern for developing great products. They reduce your agility and opportunities to learn.
In response to these slowdowns, companies make releases larger and move to large project models to govern and control the dependencies. But this compounds the problem and makes it harder to deliver great products.
The usual response is… plan the hell out of it
Organisations usually try to map out dependencies. You will have most clearly seen these in waterfall project management. But just because you are agile, don’t think that they don’t exist. If team topologies are not correct, then they pop up again and again. In part, processes like Scaled Agile were designed to help manage dependencies but critically don’t address the root cause. Because of this, you’ll see their dependency boards get more complex iteration by iteration. Let's look at a real example:
Case study: removing dependencies, step by step
In 2020, I joined a large UK service organisation. Their annual initiatives plan contained 32 separate items across 18 agile teams. The picture was similar to the previous one when very few priorities had been delivered. In response, the leadership team planned to map and manage dependencies to control the problem.
But, because multiple teams were needed on almost every initiative, work was gridlocked. After allocating the first three priority initiatives, we knew that priority no. 3 could not start for six months because two critical teams were unavailable. Initiatives 4-32 were even less lucky: many had no hope of completion within the year. In fact, we found that 64% of the prioritised initiatives required at least four teams to get live.
The dark before the dawn
When I looked at all the dependencies this way (See below, a simple table with priorities down the left, teams across the top, and cells highlighted to show team and initiative intersecting with the estimated effort.), I demonstrated to the leadership team why this would stop them from delivering on the organisation's priorities for the year.
Together, we urgently needed to address short, medium and longer-term actions to enable all 18 teams to deliver value for the company and its customers.
Short term: reduce the size of deliverables
Our immediate priority was to break the initiatives into smaller chunks. We decided that only two teams could be dependent on one another. This reduced complexity by a factor of 10. We remained focused on the priority order of projects, but this one simple change reduced the impact of time clashes. If a team had to wait for another's availability, they could now re-arrange their work and keep moving.
Medium-term: democratise skills
Next, we needed to address the structural weaknesses in the teams. Which team were the others most dependent on, and how do we democratise that group's ability/skills?
A standard solution here was to train engineers in the delivery team on how to make changes in that other system. We would retain two system experts (owners) overseeing code/release quality and standards.
Note that this type of activity can uncover critical weaknesses in the organisation's capabilities. We found two of these. A crucial lack of fundamental agile delivery skills in teams - requiring us to hire eight more agile delivery leads and a single point of failure in the knowledge of the old web app code base, which we had to address with urgent training of three more engineers. These are significant gaps that will require funds and time to solve.
The first of this democratisation reduced dependencies by 10%, though subsequent activities have a lower rate of return; cumulatively, this has a massive impact. Remember not to stop at the skill in a team: go further. You are also a dependent if your skill is unique to your team, cross-train inside your group.
Longer term: align on customer outcomes
The immediate steps were helpful, but as work in progress reduced and agility increased, other rocks appeared that needed to be dealt with. We uncovered other limiting factors around skills, abilities, and knowledge. For example, the product managers stretched across three teams. So, we switched from having teams orientated around specific technology or features to groups focused on particular customer outcomes and user journeys.
As a result, the teams could now deliver on whole experiences, end to end. Organising work around journeys aligns resources, systems and priorities in one group, avoiding dependencies. Customer journey teams are considerably harder to deliver but have the most significant payback.
💡 Note: The value journey you focus on is influenced hugely by the type of work you do. Value delivery is very different in service organisations compared to project organisations. This is worthy of a separate discussion.
Results
As we moved along this journey, products improved at an accelerating rate. To recap, I used this process:
Count the dependencies
Report the number to the management team weekly
Team-level effort to break work up
Department-level change to hire and cross-train skills
Organisational backing to pilot and then move to customer journey teams
Leadership supported when teams asked, for example, enabling the need to democratise system access but retain quality. By far, the most complex challenge was the organisational change needed to support customer journey teams. Not with the actual team members but with those who previously saw their role in telling teams what to deliver.
How low should I go on dependencies?
The reality is that some dependencies are inevitable. Maybe several teams need to update products by a legal deadline. There could be a need to replace obsolete code or a system to avoid additional costs. Dependencies are even sometimes helpful.
Here though, consider the complexity dependencies bring. If you had 2 or 3 dependencies across your organisation, you and your teams could probably keep those mentally on hand and can make intelligent decisions. You can work out what happens if more than one dependency changes. Scale that up to 10 dependencies then you'll physically require a plan to visualise the problem.
In reality, consider just having a handful. No more than five across the organisation. Few enough to act in concert but not so many that you cannot conceive of the impacts of changes, and you'll likely be in a sweet spot.
If you only remember one part of this article…
Ultimately, controlling dependencies is like any other KPI, but this one says how well your organisation delivers excellent products.
Find the dependencies, count them, kill them, and go and build great products because you will have removed a significant barrier to being agile. Remember to share this article if anyone suggests creating a plan for all the dependencies.
Lastly
This article on dependencies comes from my experience. But what is your history and experience with dependencies? How do you work within and around dependencies? Do you work in a serial process where dependencies are a way of life? How have you reduced your dependency on dependencies? Comment, subscribe, share and join the discussion.
 | A guest post by
|
Great article. The idea for mapping dependencies in a table is particularly actionable.