Reading Time: 7 minutes

How To Manage Dependencies

Main Takeaways

Reading Time: 7 minutes Software Project Management is managing all kinds of Dependencies. We have to deal with Technical Dependencies due to the SW tools we use and the product architecture decisions we agreed to. And we have to deal with non-Technical Dependencies caused by workflow and team dependencies due to the organizational work model and the design of our organization.

Technical And Non-Technical Dependencies

In the broadest sense software project management is managing all kinds of Dependencies. We have to deal with Technical Dependencies due to the SW tools we use and the Product Architecture decisions we agreed to.
We have to deal with non-Technical Dependencies caused by workflow and Team Dependencies due to the organizational Work model and the design of our organization in departments and expert groups, how the work is structured in preceding/following activity relationships, and other planning Dependencies like third-party Products/services, or working with non-Agile groups, to name a few.

When we develop Products we can't avoid Dependencies. Although Zero Dependencies is – in analogy to Zero trust in IT security – a common trend on the internet. However, it's wishful dreaming. The last consequence, concerned with Technical Dependencies, results in full-stack code ownership. And, for non-technical and workflow Dependencies the consequence is the complete isolation of the teams and their full authority and responsibility to do all the work by themselves only with no external support.

In contrast, if agile Value-driven Teams should deliver rich Customer/User Experiences, they have to have Dependencies. They have to collaborate.

Per se, non-Technical Dependencies are not bad.— A Team without Dependencies to other Teams is a silo.

In consequence, we have to differentiate between good and bad Dependencies and have to eliminate the latter only. It's quickly speaking.

Bad Dependencies are situations that prevent the Teams from discovering or delivering Value to Users and Customers.

– (Appelo 2022a).

At least

Without good interactions between Teams, we will have an overly-fragmented User Experience.

Non-Technical Dependencies are Dependencies caused by the organisational Working Model applied. Essential for bottlenecks are External Work Dependencies. External Dependencies occur when the Team's work success depends on work to be done by someone outside of the Team. By External I understand as well External-External in the sense of third-party suppliers or services outside the manufacturing organization as well as Internal-External, where the work depends on work done by other Teams or Departments inside the manufacturing organization. This could be a database admin changing a table, a developer from another team who is the expert on a certain code library, or a needed approval (review) of a pull request. In both, due to waiting for the externals, the Team can't reach its Sprint result even if they finish their own work. And the un-done backlog item is carried over to the next Sprint. This is very frustrating for the Teams.

In large organizations adopting Agile, all kinds of External Work Dependencies are very common. The reason is that the organization starts its journey by setting up its Development Department as the Island of Agility. Whereas on the Agile Island people embrace Agility and aim to make the best of it, the rest f the organization – the mainland – is far from Agile and has its own, different idea of priorities. Usually, traditional Project Management Departments (PMO) and Quality Assurance Departments live on the mainland and ask constantly the Agile Island for compliance with processes and long-term plans, deadlines, forecasts and tight schedules.

A very painful situation is when even on the Agile Island the Teams have Non-Technical Dependencies internally. It's caused by either (1) the Teams are set up with cross-functional competencies only inside the team without giving competence or authority to do full end-to-end work. Or, (2) on the Agile Island are some teams not working in an agile way. Resulting, that customer-centric end-to-end work being only possible when all necessary teams collaborate together. Worst they do this in an "agile" work chain. – Welcome Scrumfall and welcome Waterfall!

We should take Internal-External Dependencies as Organizational Debts. Analogue to Technical Debts (technical leftovers of implementational shortcuts or short-term decisions) Organizational Debts are legacies of taking over the old working model into the new world without getting rid of all its deficiencies. We should take Organizational Debts as being temporary. We should pay them off as fast as possible otherwise they get more and more expensive, hindering us continuously to do customer-centric end-to-end work and Value creation.
Badly, large organizations keep their old working model as long as possible or worst don't change it fundamentally. With small modifications only, the old model is sold as the new agile working model.

Mostly, Internal-External Dependencies and Organizational Legacy Debts are caused by staying at Work Areas being grouped in development activities related to the Product's Architecture decisions as long as the organization can. Development Work Areas tend to be more fixed over the lifetime of the Product. They focus on Architecture and are characterized by code ownership per sub-system.
Instead, Customer-Centric Work Areas focus on the Customer and are organized around Customer Requirements and Needs. Customer-centric Work Areas are temporary in nature and should change over the lifetime of the Product, but not at each development iteration. They have collective sub-system code ownership.

We are heading to Agile Value creation only and get rid of Internal-External Dependencies if we drastically revolve the existing working model from Development to Customer Work Areas. Everything else creates more Complexity in our daily work satisfying customer needs. And many large organizations fear doing this. They camouflage instead their legacy working model with pseudo-agile concepts.

Identifying Dependencies

There are two prominent ways to identify non-Technical Dependencies.

Search bottlenecks in the workflow. Bottlenecks might be administratively needed activities, or lack of resources or of knowledge/competence (e.g. subject matter experts, SME) to name a few.
Identify the area(s) of competence needed from outside the Team. The idea of end-to-end responsibility of Teams for their Products implies the Teams have all the necessary capabilities and competencies. If Teams need external expertise that blocks the Value stream.

In Agile and Scrum-like Product Development, the development process is described by so-called Product Backlog Items (PBIs) aka User Stories. A Product Backlog Item isn't a requirement with its specifications. Instead, a Product Backlog Item is a communication scheme to start conversations with Stakeholders, and Customers/Users about the Purpose and Usage conditions of Features needed. Over time a hierarchy of PBIs emerged: User Stories (the smallest unit), Epics (collection of multiple User stories), and Sagas (collection of epics). In some agile terminologies, Themes and Initiatives are synonyms for Sagas, in others, they are larger entities than Sagas. It depends on the agile terminology you use. However, all these notions aren't part of Scrum the Scrum Guide defines. The Scrum Guide only refers to Product Backlog Items.

However, we can identify Dependencies (in the sense of needed collaboration between Teams) on all levels of Backlog Refinement:

On Saga level: Initial Saga creation and follow-up Saga refinement. — Try to identify potential cross-Saga-dependencies when creating the Saga and follow-up refinements.
On Epic level: Detailing Sagas into Epics and follow-up epic refinements. — Try to identify additional potential cross-Epics-dependencies when Sagas are sliced into related Epics.
On User Story level: Detailing Epics into User stories and follow-up User story refinement. — Try to identify additional potential cross-User stories and follow-up User story refinements when Epics are sliced into related User Stories.
On Daily base: Daily scrum meetings (Stand-ups). — When the team discuss the daily plan they should identify potential blockers.
On Blocker level. — Anticipate dependencies by studying historical blockers. If you want to understand what dependency (aka potential future blocker) risks are worth paying attention to, study historical blockers from previous programs (Yip 2023, Jan 12).

Breaking Dependencies

To break non-Technical Dependencies we have to change organizational boundaries. Agile Value-Driven Teams have two options to change their boundaries:

to restructure once to dismantle Dependencies permanently or
continuously dissolve and re-form dynamically depending on the work Complexity or required skill set to handle the workload.

We can do the second one either before each new project starts or during the project before each new Sprint starts.

Most of the well-established concepts to break Technical Dependencies can easily be transferred to breaking Dependencies of organizational design and workflow: modularization with autonomy in module design, loose coupling, and specification by interfaces/handovers.

Customer-centric Modularization — Organize the wanted functionality in Work Areas by grouping all customer-centric end-to-end activities needed. Break up technical Component Areas into Customer Requirement Areas.
Autonomy of Work Areas — An organizational Change in a Work Area or its implementation (work results) should be possible at all times and should have no consequence on the results of other Areas as long they meet the specified technical and organizational Interfaces. You can give Autonomy to Teams or Areas by freeing code ownership only.
Interfaces — specify handovers on technical and organizational levels between Work Areas as a strict working protocol that must be met. Changes are only allowed if all Areas consent. For this, Modularization and Autonomy of Work Areas are prerequisites. You can rely on Interfaces only in case of Modularization and Autonomy.
Organizational Loose Coupling of Work Areas — Design the Work Area network in a way to change connections/interfaces easily if needed.

These techniques are very challenging for development organizations with a long tradition reflected in their code base. The myriads of existing repositories cause huge learning curves for newbies and multiple coding errors for seniors. Maintaining existing functionality or implementing new ones affects hundreds of repositories with their own unique code ownership.
A nightmare.
Beware, before you can benefit from breaking Dependencies easily and continuously, you have to untangle this mess of Technical Debt first. To have the capacity needed, you have to have to accept the valley of tears in reducing innovation as much as possible.

Methods to Break Dependencies

Break non-Technical Dependencies by reshaping existing, departments, Teams and working groups. Jurgen Appelo presents a list of 10 bad Dependency Breakers (Appelo 2022b).
There are other interesting approaches to reshaping Teams dynamically as well.

Dynamic ReTeaming Patterns to move Team members around Teams in different ways (Helfand 2019).
Dynamic Value Stream Crews and Dependencies Breaking Patterns. There is a larger pool of people, organizing themselves around the work at hand. As a larger group, they have the opportunity to be truly cross-functional, so that they can cover the complete Product experience or Value stream, unFIX framework (Appelo 2022b).
Fluid Scrum Teams to cope with Dynamic Workload Changes. Fluid Scrum Teams organize themselves based on the work at hand. Every time new topics need to be addressed, the people of the fluid Scrum Teams organize themselves to optimize the chances to succeed with their challenges (Ageling 2021, Jan 17).
FAST Agile. FAST is an acronym for Fluid Scaling Technology. FAST Agile does not build on static Teams. Instead, it creates a fluid lattice where Teams dynamically form, change, dismantle, and reform (Quartel 2022).
InnerSource. Code ownership in large organizations is treated similarly to Open Source projects. Everyone can change the code. Before taking on any major change, the Team making the change must go through a design discussion on changes planned with the owning Team. No code will be accepted without adequate test coverage. All changes have to go through peer-reviewed pull requests (@jukesie 2018).