A blocker waiting to happen (and it works both ways)

A blocker waiting to happen

That’s a rather informal definition and it’s not strictly accurate (some blockers are unrelated to dependencies), but it will do! Certainly it’s more helpful than Wikipedia’s:

[A] dependency is a link amongst a project’s terminal elements.[citation needed]

In our consciously inclusive and non-prescriptive way, the full version of the Agendashift values-based delivery assessment implies two kinds of dependencies:

1.5 We identify dependencies between work items in good time and sequence them accordingly
1.6 We identify and manage dependencies on external teams or services

The first of those is usually straightforward to deal with: we take care not to start a work item (some kind of deliverable – a feature, say) until we know that its dependent work items (other features or required infrastructure) will be in place. In the simplest case, we just sequence work items into some natural order and deliver them one by one. We must be a little more careful if we want to take advantage of our capacity to work on items in parallel, but still the advice mostly boils down to the mantra “Don’t start what you can’t finish”.

That mantra applies to the second kind of dependency also. Here, we know (or really should know) that we can’t finish a work item without some external contribution. Even the best cross-functional team will find itself dependent on others from time to time! Under these circumstances, if our work is to flow smoothly we must be take active steps to ensure that things will come together at the right time.

That in turn means being in the habit of identifying our dependencies in good time, keeping them visible so that no-one makes the mistake of starting work prematurely, and engaging appropriately with the people on whom our work’s completion depends.

A Story Map with external dependencies:  note the red flags bottom right

Just-in-time: It works both ways

Most people will read “appropriately” as “early enough” – early enough to ensure that our work won’t be delayed. This is a slightly selfish view however, and it’s worth looking at this from the perspective of the team on who we depend. From their side, a piece of work that is started too early is a piece of work that can’t be integrated, tested, deployed, validated, and so on. Ugh! This is the kind of work-in-progress (or inventory) that the organisation as a whole really doesn’t want. If we’re really serious about flow in the presence of dependencies, the Lean idea of just-in-time (JIT) implies some two way commitment!

This is one reason why the concept of service is so helpful. Whether customer-facing or internal, an effective service combines two things:

  1. A strong sense of what we’re delivering, to whom, and why
  2. The ability to manage expectations around performance

service-oriented organisation has both of these firmly established on both sides of all its dependencies, achieved through mainly bilateral coordination, not overly reliant on organisation-wide synchronisation. A very good thing to strive towards.

Do you find yourself continually struggling with dependencies or (the flip side of the same coin) excess organisational inventory? It’s a solvable problem. Get help!

Blog: Monthly roundups | Classic posts

Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s