Dependency Management

Press play to watch Joey share some initial approaches to identify the challenges and define solutions as you get started with managed evolutionary change in your Scrum team.

Stay Tuned!

We will add more to this blog post over time. If you would like to be notified about other problems and potential solutions for Scrum Masters, please use the sign-up box below to join our Scrum email list. 

Dependencies Happen

If you’ve read the 2020 Scrum Guide, you know it calls for teams that are cross-functional (meaning that team members have all the skills necessary to create value in each Sprint). However, almost every team we’ve spoken with is missing one or more skills or capabilities to complete their work.

These capabilities are often provided by other teams, parts of the business (e.g., procurement don’t get us started), or by an organization outside of the business (e.g. vendors, regulators, etc.).

It’s not uncommon for teams to have missing capabilities which then create dependencies on other service providers. In the graphic below, you can see how a team doing great work needs some extra capability that they don’t already have on their team (e.g., an accessibility expert). In this post, we’ll explore how the Kanban Method can address this kind of challenge.

Dependencies can have a significant impact on your team’s capability to deliver value to customers. In one team, we observed that more than 66% of the lead time (e.g., the time the work took going from product backlog to done) was spent waiting for the work to be released by a separate “release team.”  

While we would all like to remove our dependencies, the truth is that they are sometimes needed either for economic, organizational, or regulatory reasons.  

Ways to Evolve

So, what are some ideas or options for managing dependencies? 

Make the dependency visually obvious 

Many teams we’ve spoken with will simply remove work from the board that is waiting on a dependency. The rationale for doing this is that the work is no longer something the team can work on, and it shouldn’t be represented on the board during the Sprint. 

While this is one solution, what can often happen is that the dependent work suddenly reappears as work to do while the team is in the middle of a Sprint. Sometimes the dependent work reappears in the following Sprint and everyone has forgotten about the dependent work.  

Rather than take it off the board, consider making space for the dependent work so it’s no longer gone. As seen in the graphic above, the work stays in place and the dependency is visualized using a “Help” sticky as a visual indicator that help from an accessibility service is needed. 

Many tracking tools provide means of marking dependencies. This could include placing a flag on the work or dedicating a special swim lane on the board for work that it stuck waiting on a dependency to give you what you need. You can also modify the title of the work to include an acronym like “DEP:”. 

Establish expectations

If your team relies on another service provider for particular capability, then it is reasonable to have expectations of the dependency. This means that by understanding how long it takes for another team to do their part, you can start to establish some expectations. Yes, we are talking about one of our favorite friends in the Kanban Method, lead time. In the context of requesting something from another team, the question that lead time can answer is “how long in advance do I need to make the request so that I can get it when I need it?” 

Using the board example above, let’s assume your team needs assistance from a shared service to provide the specialized accessibility capability. We’ll call that team; Team A. Team A has a lot of accessibility experts that you need advice from during the Design activity. Your team regularly makes request of Team A. When those requests are made, there is no expectation given for how long it might take to get the support your team needs so that you can continue to deliver the value on the work. 

This is a good time to start tracking when your team makes the request to Team A and when you get what you need from Team A. When we track lead time, we usually track it in number of days. As an example, let’s say that the last time your team asked Team A for support, it took 6 days.  

Over time, you can collect enough lead time data to have some meaningful conversations with Team A around expectations.  

Develop an escape hatch

Sometimes your team might feel like its request is being ignored by your dependent service provider. This is not uncommon when making sizeable requests.  

In one example, we discovered that a website team needed a large amount of data from a data team as part of their planned quarterly effort. The website team that needed the data was not allowed to have access to data unless they requested it from the data team. Effectively, this capability was not permitted on the website team as part of a management or leadership choice.  

Once the quarter started, this website team reached out to the data team to ask for the data. They were told that this request wouldn’t be supported or serviced in the current quarter. Yikes! How do you work with this challenging data team?  

Escalate – When you can’t get the service you need, you might want to consider escalating the risk and need of your team’s work. This means escalating to the managers and leaders accountable for the results of the teams. While this is not something you want to do frequently, it is sometimes the right thing to do when the risk of delay is known, and the impact is high for your work.  

Workaround – You can also work around the dependency. Sometimes a good approach is to avoid or work around the dependency to get the majority of what’s needed done. The website team may have been able to initially use what is called “stub” or fake data in the interim to develop the functionality needed without having the data from the data team. In a future quarter, the team could refine their development using the real data provided by the data team. Or the team may evolve to continue using this workaround and adopt it as a new “adaptation” for this type of dependency issue. 

Help – perhaps the answer is simply lending a hand to the data team. We see this pattern show up when teams value collaboration and coordination regardless of position in the organization. Developers help testers and testers help developers. Cats sleeping with dogs and dogs sleeping with cats. It can happen and it’s not a bad idea to offer help to a team that can’t support your request because they don’t have enough support on their team. 

Accept – While not always a great decision, the website team might have to accept the truth that things aren’t going to change. Plans will need to change. This means potentially reworking the schedule and forecasted effort for the quarter.  

In the case of our example, this is what the website team ultimately chose to do. They initially chose to escalate their dependency to get what they needed from the data team. During the escalation effort, they discovered that the data team was working on a request that was even more critical than their own project.  

While the website team had a valuable need to escalate their request to the data team, they ultimately chose to accept the data team’s current request was more valuable than their own request. The website team rebuilt their plans for the quarter.  

Want to Share Your Opinion?

Please contact us and let us know what you think. Is this what you would do for dependencies? If not, what have you done? We’re always learning here at Kanban University. 

Learn More

Want to learn more about how Scrum can be better with Kanban? Then you might want to check out how to improve your Scrum with Kanban training.

Stay Tuned!

We will add more to this blog post over time. If you would like to be notified about other problems and potential solutions for Scrum Masters, please use the sign-up box below to join our Scrum email list.