PM and Managing Dependencies

Managing dependencies is a critical part of TPM responsibilities. Dependency management can make or break a project. Unmanaged dependencies may result in work wastage, re-work, broken functionality and significant churn and stress for multiple teams.

The first rule of thumb is to eliminate dependencies. The less dependencies you have the better it is. In this article we will talk about various types of dependencies in different stages of the project and how to manage them.

There are two types of dependencies; Intra-Team dependencies and Inter-Team Dependencies.

Intra-Team Dependencies:

• Requirements Dependency

• INVESTable User Stories

• Architecture and Design

• Build Feature Teams/Cross functional Team

• Hiring/Picking T-shaped Skill set

• Tracking Tools/Dependency Radiators

Inter-Team Dependencies:

• Automation

• Do it Yourself

• Do it Together

• Mock the Dependency

• Wait it Out

• Use Standardized Processes

• Go around the Dependency

• SCRUM of SCRUMS/Attend Standups

• Frequent Check-in/Status Meetings

• Micromanage

• Use Cross Group Roles

Intra-Team Dependencies:

Requirements Dependency: TPM is dependent on the Product Owner to write the requirements in the form of user stories. The best way to handle this is to have a regular sprint backlog grooming meeting on the calendar. This meeting is attended by Product Owner, TPM, Engineers and extended team members like Business Analysts and System Analysts. TPMs can also write user stories with the help of Product Owners/Engineers. You can read my article on TPM role in Sprint grooming for more details.

INVESTable User Stories: If user stories follow INVEST framework (Independent, Negotiable, Vertical, Estimable, Small and Testable) then they will have minimal external dependencies.

Architecture and Design: Many dependencies can be eliminated in the architecture and design of the application/service. Modular design is one such technique. Simplifying the architecture reduces the complexity. Many dependencies are due to unnecessarily complicated architecture and design.

Build Feature Teams/Cross functional Team: Building feature teams and cross functional teams as opposed to component teams also helps in eliminating and reducing dependencies. Component teams are split based on components/functions like front end, middleware, backend, deployment etc. This results in huge dependencies across teams for anything valuable to reach the customer. Feature teams or cross functional teams has all the resources like Dev, Test, UX, Operations etc. to build and deploy a feature in production.

Hiring/Picking T-shaped Skillset: T-shaped skill set represents team members with an area of deep expertise (represented by the vertical bar in T) along with a set of broad skills (represented by the horizontal bar in T). Having this composition increases the probability of having deep expertise on a range of skills as well collaboration skills within the team and reduced dependency for expertise outside the team.

Tracking Tools/Dependency Radiators: Making the dependencies visible in planning tools helps keeping it fresh in the mind and easy to track. If you are using physical boards, you can make connecting lines between the dependent stories. In virtual tools, you can add a visual indicator or even create dependency stories which can be moved on the board as the partner team progresses on them.

Inter-Team Dependencies:

Automation: If the process around the dependency can be automated then dependency will be removed. Let’s take an example, until few years back, there used to be a separate operations team for deployment. These days with CI/CD pipelines, engineers can do the deployments. This has removed the operations team dependency.

Do it Yourself: In many situations, its just easier for the team to do the work by itself. This could be due to multiple reasons – work is super critical, blocking multiple items, low reliability partner team, schedules not matching etc.

Do it Together: One option is to execute on dependent items together by two teams. In real life it may not be practical. Matching the priorities and schedules across multiple teams is difficult. If it does happen, then SCRUM of SCRUMs or attending/inviting representatives across the dependent teams can be useful.

Mock the Dependency: While other teams may not entirely build the component for you, there is high possibility that they can share the contract or unit tests ahead. This unblocks your team and it can continue with the development. Be aware that things may change along the course, but it is way better than waiting to start at all.

Wait it Out: It is also known as the gatekeeper approach. While it may not be feasible in all situations, team may continue postponing items which have external dependencies as much as possible and execute only when it becomes absolutely necessary.

Use Standardized Processes: Use standardized processes published by partner teams for managing dependencies e.g. Security and Privacy team may have 2-week SLA for completing the first assessment. Platform team may have 2-day SLA for configuring Cloud accounts, Hardware team may have 1-week SLA for provisioning the laptops for new team members etc. Many of these SLAs are negotiable if a sense of urgency is conveyed to the right people and in the right manner. Some of these can also be mitigated e.g. using ephemeral cloud accounts, letting BYOD (bring your own device) to work etc.

Go around the Dependency: Sometimes you can go around a dependency or get an exception approved e.g. company has a code freeze but if you show enough urgency and detail, you can deploy your feature/fix in production.

SCRUM of SCRUMS/Attend Standups: Having a SCRUM of SCRUMS or attending standups of other teams with dependencies is beneficial in tracking progress. It also shows commitment from all the involved teams about managing dependencies in an open manner.

Frequent Check-in/Status Meetings: Check-ins and status meetings are another great way of tracking the progress on dependencies. They can be weekly or biweekly as needed. All teams with mutual dependencies for a release send a representative to give status on the dependency items.

Micromanage: Although, not preferred, this may be required if the partner team is not delivering and stakes are very high. You may be required to follow up with them frequently and track progress closely to know when your team will be unblocked.

Use Cross Group Roles: Many organizations have cross group roles like cross group program managers. These people are responsible for coordination amongst multiple teams. Knowing who they are, what is their charter and where they can help can be useful in managing dependencies.

While we have covered multiple tools and techniques above for eliminating and managing dependencies, one of the strongest tools in a TPM’s toolkit is networking and good working relationship across teams and divisions. There are multiple ways of developing this network like taking part in any v teams (virtual teams) being built for cross company initiatives, showing up at company events, attending roadshows and marketing events of other departments of your company etc.

Discuss in the section below what has worked for you in managing dependencies across your projects!