Workflow Dependency Management

👉 Map Dependencies to Find Bottlenecks It is hard for a team to ship fast when it has to wait on other departments, teams, or suppliers to do something they depend on. 💤 For example, when deployments are performed by an external team that is swamped with other work. Or when another department has to perform specialized testing before approval is given. Whatever their dependencies, they are generally outside of the control of a team. 🤷♀️ That makes the delays unpredictable. Even when a team considers something “Done”, weeks or months may pass before their work actually reaches stakeholders. This greatly impedes a team’s ability to work empirically and reduce the risk associated with complex work. This experiment is about creating transparency around dependencies and their effect on your team’s ability to ship fast. It was inspired by the Dependency Spiders in Jimmy Janlén's “96 Visualization Examples” (which contains many other awesome visualizations 🎉 ). To implement this experiment, do the following: 1️⃣ Draw your team in the middle of a big piece of paper. Together, create a list of the teams, people, and departments you frequently need something from to create a Done Increment or release it. Whose approval do you need? 🤔 Who needs to perform an activity for your team to continue? Draw the sources you depend on around your team, like the legs of a spider. 🕷 2️⃣ Whenever your team needs something from someone outside the team, capture the request and the date it was issued on a sticky note and put it next to the source on the canvas. When the request is fulfilled, write the number of days you had to wait on the sticky. At the end of the Sprint, calculate the average wait time in days for all the fulfilled requests and move them to an archive. 3️⃣ Use the Dependency Spider and the average wait time as input for your Sprint Reviews and Sprint Retrospectives. 🤔 What actions can you take to reduce the impact of dependencies on your ability to ship? 🤔 How can you include and collaborate with them to remove or reduce dependencies? 🤔 How can you leverage support from your Product Owner and stakeholders to change your team's environment so that you can ship value to them faster? What are your thoughts after reading this post❓ What other ideas do you have❓

Agile: It Depends Sorry, purists, but cross-team dependencies are a reality, even in Agile environments - and especially when scaling (e.g., SAFe). Agile teams are independent, but don't (or shouldn't) work in isolation. Dependencies, whether they're due to shared systems, limited expertise, or interconnected work products, can disrupt flow, cause friction, and delay value delivery. When they can't be eliminated, then managing them effectively should become a core team skill in any complex, interconnected environment. Dependencies Dependencies emerge when one team’s work relies on the completion or input of another team, ART, or external group. Left unmanaged, they create bottlenecks, misalignments, and delays, threatening Agile’s focus on predictability. The ideal scenario minimizes dependencies, but practical constraints like limited expertise or tightly coupled systems mean they can’t all be eliminated. So, the focus must shift to managing dependencies with transparency and collaboration. Visualization Make dependencies visible. Tools like dependency maps, inter-team Kanban boards, or visualizations in platforms like Jira (e.g., BigPicture) help teams see connections and track progress. Effective visualization highlights critical handoffs and potential delays, enables teams to monitor dependency resolution in real time, and provides a shared understanding for better coordination. During PI Planning, teams can use dependency boards to identify risks, align timelines, and agree on milestones. Be Proactive Dependencies must be identified as early as possible to reduce surprises. Teams should surface them during Agile events During PI Planning, teams collaborate to uncover cross-team dependencies and plan solutions. Reviewing stories during Backlog Refinement allows teams to flag and address dependencies before they become urgent. By proactively identifying dependencies, teams can align their schedules, coordinate integration efforts, and mitigate delays before they impact delivery. Accountability Every dependency needs a clear owner. Without ownership, accountability gets lost, and dependencies become a source of frustration. Ownership means assigning a team or person to manage each dependency, setting clear agreements on timelines and expectations, and checking progress regularly to maintain alignment. This reduces ambiguity and fosters trust. Reduce Impact Some dependencies are unavoidable, but teams can reduce their impact through thoughtful technical and architectural choices. Designing modular systems, using feature toggles, and automating shared tests are just some of the practices that can help teams work more independently. It Depends - But It’s Manageable Dependencies may be unavoidable, but they don’t have to be disruptive. By visualizing, identifying, owning, and mitigating dependencies, teams can maintain flow, improve collaboration, and deliver value predictably. Doing so is a skill every Agile team must master.

Mastering Project Scheduling & Dependencies: The Key to Seamless Execution. I’m writing this post based on a recent experience, reflecting on my own thoughts and learnings while managing dependencies in a complex project. Overlooking even a single dependency can cause major delays, and proper scheduling is what keeps everything on track. Project success isn’t just about great ideas—it’s about flawless execution. And at the heart of execution lies project scheduling and dependency management. In my experience managing projects across diverse domains - I’ve seen how mismanaged dependencies lead to bottlenecks, delays, and misalignment. Understanding different dependency types is key to keeping projects on track. The Four Start-Finish Dependencies in Project Scheduling ▶ Finish-to-Start (FS) – The most common dependency where a task must finish before the next one starts. Example: Design must be completed before development begins. ▶ Start-to-Start (SS) – Tasks can start simultaneously but may progress independently. Example: Frontend and backend development can start together but follow different timelines. ▶ Finish-to-Finish (FF) – One task must finish at the same time as another. Example: Testing and documentation must be completed before deployment. ▶ Start-to-Finish (SF) – A lesser-known dependency where a task cannot finish until another starts. Example: A night shift worker cannot finish their work until the next shift starts. Best Practices for Managing Dependencies & Scheduling ✅ Identify and Document Dependencies Early – Use dependency matrices or project planning tools to map out relationships between tasks. ✅ Leverage Parallel Execution Where Possible – Reducing sequential bottlenecks increases efficiency and shortens timelines. ✅ Mitigate Risks with Buffer Time – Account for potential delays, especially in sequential dependencies. ✅ Ensure Cross-Team Coordination – Dependencies often involve multiple teams. Clear communication prevents roadblocks and misalignment. ✅ Utilize the Right Tools – Gantt charts, dependency maps, and project management software help visualize dependencies and manage execution effectively. A well-structured schedule with well-managed dependencies transforms chaos into clarity, confusion into confidence, and delays into deliverables.

Your project isn’t late. Your dependencies are. Every project manager has lived this pain: You do everything right… and still slip behind schedule. Why? Because half of your plan depends on people you don’t manage. And somehow, they always “just need one more day.” Here’s how I manage the dependency trap: 1. Visibility Map every external dependency early. If I’m waiting on you, you are on my radar. 2. Buffers Add breathing room where others own the work. Not pessimism, just math. 3. Proactive escalation If a dependency looks shaky, raise the flag before it collapses. Leaders can handle bad news. They hate late news. (and yes, more than budget cuts). Do I eliminate risk this way? No. But I make sure we’re ready when risk becomes reality. Because the truth is… Projects rarely fail inside the team. They fail at the handoffs, usually with an excuse attached. ↳ How do you keep dependencies from derailing your projects?  

Early in my career, I believed dependency lists were reliable. Every plan template had a section for “Upstream Dependencies,” “Downstream Dependencies,” “Critical Vendors,” “Systems Required,” and so on. So I did what everyone does: I sent the spreadsheet. Teams filled it out. I checked the box. It all looked tidy… until an actual disruption punched through the façade. That’s when the surprises came out: “We need Finance to approve that.” “We didn’t realize Legal touches that workflow.” “Procurement is involved? Since when?” “Wait—if that team goes down, we can’t do our part at all.” Different industries. Same pattern. The problem wasn’t the spreadsheet. The problem was the illusion that people can list interdependencies in isolation. People know their own work. But they rarely see the connective tissue. Here’s what I wish I knew earlier. 1️⃣ Interdependencies are exposed through conversation, not forms When two or three teams walk through how work actually moves between them, the truth shows up instantly. I’ve watched teams discover missing dependencies they’d carried for years—simply because no one had ever facilitated the conversation. This builds accuracy and engagement. 2️⃣ Most dependencies aren’t technical—they’re human Spreadsheets capture systems. They miss people. Every role has informal influencers, bottleneck decision-makers, and quiet subject matter experts whose absence causes a slowdown no template can predict. When I ask, “Who do you call when you’re stuck?” I learn more in 10 seconds than in 10 spreadsheet columns. 3️⃣ Dependencies change under pressure Normal operations and disrupted operations do not use the same pathways. In both healthcare and tech, I saw that when systems failed: Teams used different communication channels, different approval flows, even different work sequences. Static lists cannot capture dynamic behavior. Facilitated walkthroughs can. 4️⃣ Map connections, not categories Instead of asking teams to categorize dependencies, I ask them to SHOW: • Who hands work to whom • What decisions depend on other teams • Where delays actually occur • Which steps are brittle or fragile • Who the “one-person dependencies” are When people see the flow, they automatically see the risks. Here's the lesson: Dependency spreadsheets fail because they try to document reality without revealing it. If I were starting over: I’d rely far less on classification and far more on interaction. Because once people understand how interconnected their work actually is, they participate in BCM differently. They see themselves in the outcomes. And that’s when engagement turns into ownership. ------------------ For anyone finding this post first: I’m sharing the lessons I learned moving from early BCM roles to leading programs in healthcare, tech, and consulting—specifically what I’d do differently if I were starting fresh as a BCM Manager today.