The not so hard art of dependency management...

Most of the software development or support teams have found themselves in a situation where they are either dependent on another team or some other team depends on them for all or part of some work. This is also a natural phenomenon in eco-systems as conventional as waterfall or project management. There can be upstream dependencies and downstream ones. Does the nature of dependency define the speed and style of communication and more importantly should it? What are some best practices that teams anywhere can use to work dependencies? Hence, welcome to Dependency Diplomacy!!!

Upstream dependency is where my team is waiting on another team to finish work before we can start our work or dependency delaying my team. Downstream dependency is where my team needs to finish work that will allow or enable another team to move on with their work or in other words, my team is causing the delay. Going back to the not so rhetorical question above whether the nature of the dependency defines or drives the speed and style of communication has as simple an answer as the question itself but most of the time we complicate it more than we should. Whether we are dealing with an upstream dependency or a downstream one, the urgency in our queries, follow up with actions and follow through with commitment for a downstream dependency should be at least as much as it is for upstream dependencies if not more. This sends the message to other teams that Team A treats dependencies with utmost urgency and does not differentiate when it comes to upstream or downstream. Over the course of time, this becomes Team A’s introduction when others talk about dependency management and it creates a sense of safeguard in relation to work handed to Team A. One more thing it does is that scrum master, product owner and development team members who have created a culture of dependency management unlike others now have a repository of best practices when it comes to dealing with dependencies. Those can in turn be used for a succession plan knowledge transfer over time thus helping the organization grow from within.

While there are a few items teams and more specifically scrum masters should be mindful about regarding dependencies, top of the list is the correct and factual identification and definition of dependency. This means we want to identify what is the dependency without bringing emotions into the mix. The dependency may block a critical piece of value we will deliver to three data centers potentially impacting customer experience. One thing we want to do is, stay true to the facts when identifying the details.

I recommend using the following questions when defining dependencies:

1. What is the dependency?
2. Which team owns this dependency?
3. Who is point of contact (POC) for the identified team?
4. What is the timeline for such dependency resolution?
5. How does unresolved dependency impact commitment for this user story (feature or epic)?

It is one thing to identify the dependencies and outline the different dimensions (mentioned above) and another to document such in the user story, feature or epic in Jira (Azure Dev. Ops. or any other database of record that your organization uses). By calling out the dependency in Jira (for purpose of simplicity) ticket, we are adhering to the very fundamentals of transparency and alignment that teams need when planning and delivering work. There are two aspects of such documentation where first one involves sticking to facts that we know today (and any subsequent day that we gather more information) and progression thereof and second is linking of Jira ticket to the ticket of the other team. If there is system limitation due to project difference, one can create a ticket for the said team and assign the said team the ticket or come up with a creative way to ensure that this dependency does not fall through the cracks.

A very important aspect of dependency management is communication. If John, who is a developer on Team A has tagged Rick (developer on Team B) for a dependency in Jira ticket PJT-001 (and assigned him PJT-002) with all the above details, then John can after pinging Rick about the same, wait for no more than twenty four hours. If it has been twenty four hours and Rick hasn’t reached out with any details or information that was required, it is best that John reaches out to someone on Rick’s team to find out what’s happening and why Rick hasn’t responded. This includes initiating contact with a human being on Rick’s team who can shed light on what’s the status of the ticket PJT-002 (it should be documented on that respective ticket). During all this communication, it is a good idea to keep the scrum masters in the loop for respective teams from a visibility standpoint. Give the second person another twenty four hours but keep documentation primarily in the Jira tickets (and follow up with email and a messaging tool ping). If it has been forty eight hours of radio silence then scrum master should engage scrum master for Team B and find out what is happening in order to help John with movement on his work which may or may not mean putting that item on hold as we move towards commitment during respective sprint planning (or just planning for Kanban teams).

You might ask that why should the team even commit work that has any unresolved dependencies? This is a valid question and a very simple answer to this is that it should not happen but we don’t live in should rather how it happens. There will be times, when teams will be forced to commit work despite better judgement and recommendations from scrum masters due to failing deadlines and budget overheads. That doesn’t mean that scrum master can’t share their concern against committing work that has unresolved dependencies. Coming back to the John and Rick show where John’s story is lined up for next sprint and it is imperative that Rick delivers his work in this iteration so John has ample time to validate any details on his end before taking up his part of the work in next iteration. This is why it is critical to follow up and follow through with communication using database of record with specific factual details instead of vague emotions or hearsay.

A major anti-pattern to avoid in terms of dependency management is to assume that people involved know there is a dependency (and details thereof). One of my coaches rightfully stated that anything that is not documented does not exist. Assuming creates grey space which makes way for conflict because of no clear expectations and role definition when it comes to respective lira tickets. It is better to document specifics than to later be on a call trying to decipher the meaning of a sentence which did not explicitly define the word ‘Authenticate’ if there are multiple meanings within the organization depending on which team is authenticating stuff. Dependencies are part and parcel of software development in medium to large organizations and it is important to create a culture where individuals and teams understand the dynamics teams have to work with in treating and resolving such dependencies. It is when we start assuming and leaving things to guesswork that a very straightforward second grade task becomes rocket science by virtue of snowball effect that could have been avoided in the first place.?

• What are the most pain staking dependencies you have experienced and worked through?
• How does your organization manage and handle dependencies?
• What best practices would you share for dependency management?