Using Kanban in Scrum Teams to Manage Dependencies

All teams that work together and collaborate have challenges. In my work as a consultant and coach I have come across some common problems that I have seen Scrum teams wrestle with. The first challenge I would like to address is that of managing dependencies.

Scrum teams aspire to work in such a way that they are completely self-organizing and cross-functional. In working with numerous Scrum teams, it has been my observation that complete autonomy and independence of this nature is lacking. No matter how hard teams try to self-organize around the work and make sure they have ALL the skills needed to complete sprint backlog items, there seems to be no getting away from dependencies that exist outside the team. If this is your reality, I would like to propose some ideas for addressing this challenge.

CONFRONT REALITY

There are numerous benefits in striving to develop teams that are self-organizing and cross-functional, and I won’t suggest that you should not endeavour to move towards this ideal. However, until you reach a point of complete independence within your team, you need to deal with the reality that dependencies exist outside the Scrum team.

Pretending that dependencies do not exist and committing to finishing work under that false pretense results in sprint commitments that continually fall short. So the first step in dealing with dependencies is to recognize that you have them. Proceeding as if they don’t exist won’t make them go away.

Do away with wishful thinking!

IDENTIFY DEPENDENCIES

Once you have accepted that you have dependencies, you need to identify them. This does not need to be an overly elaborate exercise. Just list them and make them visible on the backlog item. For example: Perhaps you are doing Sprint Planning and you discover that a particular story will require design work from a specialized design person outside of your company who is not part of your Scrum team. Make this dependency explicit and visible!

Dependencies pose risk to our Sprint commitments. In Kanban we use the practice of visualization, which includes visualizing risk. Once we visualize risk we can “do something about it”. We can have conversations about the risk and take appropriate steps in efforts to mitigate it.

ALLOCATE CAPACITY ACCORDINGLY

Now that you have made an effort to identify the items that have dependencies, you might want to consider these risks when you are selecting work for your Sprint backlog. Loading up your Sprint with too many items that have dependencies is going to expose you to more risk than you might be comfortable with. Perhaps you decide to allocate capacity in your Sprint backlog to no more than 1 or 2 items that have external dependencies – with the rest of the items NOT having dependencies. In this way you are balancing the risk profile that you are willing to accept into the Sprint.

Understanding the risk associated with the work items you commit to is an important part of replenishing your Sprint backlogs. Don’t overburden your Sprint with work that has too many dependencies. Allocating capacity across a healthy mix of work items that span multiple risk dimensions (dependencies being one of them) is a common technique in organizations using the Kanban Method.

MANAGE DEPENDENCIES PROBABILISTICALLY

Much of the work we do in Sprints is complex. Work that is complex in nature does not have a clear relationship between cause and effect. This would explain why we are awful at estimating and trying to predict how long it will take something to be done. This is particularly problematic when dealing with dependencies. If we are to try and manage our dependencies effectively we need to shift our thinking from a deterministic to a probabilistic paradigm. How do we do this?

Stop estimating and limit the amount of upfront planning you do for your backlog items and Sprints. Instead, start measuring how long it takes you to do certain types of work and develop Service Level Agreements (SLA’s) based on that. Instead of trying to guess how long you think a work item is going to take, look into the past and see how long it “actually” took you to do that same type of work. It will “probably” take you around the same amount of time the next time you attempt work of this type. What would this look like?

Perhaps you have a type of work, let’s say a Report, that always requires the aid of an external dependency. Make note of the Start Date when you start working on this item. Also make note of the End Date, when this item actually gets finished. Subtracting the End Date from the Start Date will tell you how long it took to get this type of work done. Start plotting these times into a chart like a Lead Time Distribution or a Scatterplot. If you do that you can then identify (probabilistically) how long it takes you to do work that has that particular dependency. For example, with a Lead Time Distribution chart that has tracked the amount of times it has taken the team to complete Reports over the last 4 Sprints, I could determine the 85th percentile on the chart and develop an SLA that might indicate something like: “85% of the time, Report work items take us on average 7 days or less to complete.” Armed with that probabilistic information, we can make sure to take that into consideration when selecting work for our Sprint backlog. 

The point here is to stress that you want to start measuring the amount of time that it takes you to do certain types of work (or perhaps all type of work). If you do this, you can start to develop SLA’s for various types of work. SLA’s not only help you manage customer expectations, but they also help you manage dependencies. If you know, probabilistically, how long it takes you to do certain types of work, then you can make sure to start that work far in advance so that it will probabilistically complete on time.

In Kanban we want to manage our work using a probabilistic construct. Doing so, we can try and make sure that the right work arrives to the right people at the right time and that we can appropriately manage expectations. 

CONCLUSION
There are numerous benefits to self-organizing and cross-functional teams, but sometimes there is just no getting away from the need to interact with other people in order to get work done. I have offered a few ideas on how to manage dependencies when working in Scrum teams. The ideas I have proposed come from my consulting work with the Kanban Method.

If you find this useful, please consider contributing with our
“Value for Value” model.