Agile Dependency Management

So if you’re following this blog or about to, you should realise that I’m not a daily blogger. It depends on how much time I have, so there will be gaps and there will probably be periods of manic posts if I get fired up about a few things (which if you follow me @RiczWest on Twitter, you’ll know I can! :)

Anyway, to the problem at hand which is one that came up recently. The environment is mainly Waterfall, with some projects partially Agile. There is quite a bit interest in “Agile Techniques” though.

Personally, I’m a big believer that you can use some Agile techniques without causing “cognitive dissonance” and blowing people’s heads up ;-) I’m very much a “whatever tool suits the job and the context” kind of guy – I live in the probability clouds between absolutes of anything.

Out of the blue, a colleague asked me if I “Knew anything about Agile?”, “A bit and I’m a Certified Scrum Master” I answered… “Then how do you manage dependencies in Scrum?” was the next question. I gave the classic response of how the process and the team deal with this because they’re empowered. “Yeah, we can’t do Scrum, but is there some Agile technique we can use?” he then asked.

“Well, you could take your Tasks, put them all on sticky notes and use grouping and discussion to work out what the dependencies are” I replied. “Yeah, that sounds good” he said, “but we’ve got teams distributed geographically and across multiple vendors” ooohh – sharp intake breath from me… hmm…

After a bit, the Scrum of Scrums popped in to my head so I suggested that each “area” could do the dependencies for their bit as originally suggested and you could then get some people from each “area” together to work out what their global dependencies across the whole project were in the same physical location. “Is this possible?” was my next question. “Yeah, I suppose we could do it for a day” he said without much hesitation.

So that’s where I am, but I have a few questions that I value people’s input on:

  1. Am I a crazy idealist? Is this pushing the boundary too far and should I just say “you can’t use bits of Agile like this as the risk is too high”?
  2. Does the “overall process” make sense? Any tweaks, alternatives, whatever?
  3. In the Dependencies of Dependencies workshop we could have, how many should come along from each area? My guess is that there are probably around 5 “areas”
  4. Does this have any chance of working? Or will it just blow up and become a “yeah, we tried Agile and it didn’t work” kind of thing?

As you can hopefully gather, I’m really not precious about this, but view it as a “potential opportunity” to get people to take a few steps “outside Waterfall” as they’re already thinking about it.



  1. Mirko

    Dependencies should be resolved such that the Scrum team can work independently during their sprint. We do this “outside” of Scrum: We ask the product owner to identify stories that are too big or to complex to fit into the Scrum box. These stories will be split before they’re put to the backlog. The splitting is supported by an architect who cares that the split causes as few dependencies as possible. However, this is kind of mix between waterfall and Scrum – but it’s the way we found useful.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your 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