Mike Lyons explains how dependencies and blockers slow projects and offers practical ways to surface, reduce, and manage them. He contrasts functional team handoffs (which multiply delay risk) with cross-functional, autonomous teams that minimize dependencies; lists common dependency types; recommends visualizing dependencies (program board) and blockers (Kanban); and suggests mitigation tactics (cross-skilling, decoupling, escalation paths, dependency reviews).
Troy McGinnis, a renowned expert in agile, project management and data driven forecasting, offers this stark insight into project dependencies. Every dependency doubles your chance of being delayed or late. Ouch. This powerful statement underscores the critical impact of dependencies on project timelines and success. Now, dependencies happen all the time. Consider cross team dependencies. Many projects have functional teams and handoffs between them. For example, we might have a user experience team who handles the design, and then we have, let's say, two development teams, the people who build the products, these are the developers. And maybe we have a testing team, a team that checks the developer's work, and then we might have an external IV and V team for their validation, and then it gets deployed. We have an operations team that actually handles getting it to the user. Now each one of them is doing a very important, although very specific, piece of the process. Not any one of them on their own is able to ship value to the customer. And so because of that, work moves from the UX team to the development team. And then the development team passes over their work to a test team. And when testing finds a problem, they pass it back to the development team to fix. And, well then the cycle starts over. The dev team fixes it and it goes back to the test team. The test team, if it finally passes, gives it over to IV and V and we know they're probably going to find problems. So they pass it back to the dev team and then it goes to the test team, maybe gets lost in the shuffle, has to get revalidated, and even when it does finally pass IV and V, now it has to go to the ops team, maybe they have a problem with the deployment and they have to reach back to the development team and ask questions. And this sort of cycle continues and you get this sort of massive cross team dependency mess. Now every single one of these handoffs requires coordination. Each one of these handoffs is a dependency. There's a well known principle in project management circles that says all risks live in the handoff. The riskiest parts of any process are the points where work, information or even responsibility is transferred from one person or one team to another. These transition points, these are where errors and miscommunications and delays occur. And if you remember from our value stream mapping exercise, most of our time is spent waiting in the delay caused by handoffs. This notion of functional teams that are just doing one thing, like test or develop, well, they drive dependencies. So an antidote to this is to create cross functional teams, teams that are able to deliver a piece of value end to end with with no handoffs to other teams. They have all the skills that they need to deliver value. When you achieve this structure, it's remarkably powerful. It effectively eliminates dependencies between teams. Autonomous cross functional teams move very quickly. They make decisions efficiently and they respond to changes rapidly. It's a fundamental shift in how we structure work to optimize for both speed and quality. Now, I see cross team dependencies all the time, so they're kind of top of mind for me. But they're certainly not the only type. Consider these other common dependencies. Technical dependencies, when one part of the system relies on another part to work properly. External dependencies relying on vendors, regulatory approvals or customer input. Skill based dependencies. That's where we need specific expertise or training to move forward. Resource dependencies like waiting for budget approval or equipment availability. Sequential dependencies. Tasks that have to happen in a specific order or at certain times. Organizational dependencies requiring decisions or input from other parts of the company. Each of these can slow down your project, just like a cross team dependency can. Being aware of them can help you spot potential bottlenecks early. And when you have those dependencies, the key thing you want to do is make them visible. One way of doing that is with a program board. Now, if you're familiar with the Scaled Agile framework, this might look familiar to you. Essentially, we're making our work visible across the entire program. Each team represented as a swim lane and the cadence or time box as a vertical column. And we show work on a card. And for each work item that has a dependency, we indicate with a line to the dependent work. The key is to make your dependencies visible, but that's not the end game. Don't just sort of accept that they're inevitable and you have to live with them. No, instead, try to eliminate them wherever you can. Here are some other strategies to address dependencies. How about cross skilling your team members? Encouraging team members to learn skills from other areas to reduce reliance on specialists. Decoupling. Look for ways to separate tightly coupled parts of the system or process and establishing clear escalation paths. Have a process for quickly addressing dependencies that are holding up work. And if things are really bogged down, consider a regular dependency review meeting. Schedule time to specifically discuss and resolve dependencies. Remember, the goal is to reduce dependencies where possible and manage the remaining ones effectively. This proactive approach can significantly improve your team's ability to deliver value smoothly and consistently. So, dependencies are one thing, but sometimes they actually block our work. So let's talk about blockers for a moment. What is a blocker? Now, there are lots of things that can be blockers, but consider some of these as examples. I already mentioned dependencies with other teams, but consider also a product owner who's not available. How about user stories that are poorly defined, lack of tools or technical resources, ambiguous acceptance criteria or definitions of done, lack of technical competence, and formal phase gate reviews? Blockers can take on all kinds of forms, but your role as a delivery lead here is to act as chief blocker remover. Okay, I can already hear the Scrum police coming to write me a ticket and say, hold up there, Mike. You're talking about the Scrum Master accountability now. Okay, yeah, I get it. Scrum Masters at the team level are supposed to handle impediments. But that said you project managers, I mean, this is right up your alley. So work in conjunction with your Scrum Masters. They absolutely know what's blocking their team. So work with them. Gather that information from them. What we know is this, in order to be successful at removing impediments, they need to be visible. Just like the program board displays dependencies, you need a way to see your blockers. One great way to do this is by using a Kanban board to make your work visible. And I have an exercise for you in the next lesson to show you just how to do it.
