Hung Up On Scaled Agile Dependency Management

Let's look together at the following photos.


Below you can see what's called SAFe Program Boards - an artefact (output) of a PI Planning meeting in SAFe.


I like the photos and the level of visualization. I think it is in general a great idea to visualize cross-team dependencies. And it is not a trivial job to do!

this one is from blog
this one is from blog

We value information radiators in agile project management due to their simplicity and power. So I appreciate that finally we have a creative and rather simple way of visualizing inter-team dependencies with colorful strings. They make us almost feel nice about those dependencies.


I'm personally a strong advocate of visual boards. And I do believe in power of visualization. Still...


Still every time I read another proud post from someone who has just done a "successful PI planning" - I feel there is something utterly wrong with it.


And I couldn't quite figure out why I felt like that until I found these images:

Finally I understood. Gosh!


Visualizing cross-team dependencies is like showing to the whole world how f**ked your company in fact is. You need to have some courage to do that! (that's why it is one of the Scrum values).


But this makes me feel sad and bad. Sad because I know how it feels being inside teams with too many dependencies. And bad - because I can't come and help.


I feel sorry for these companies.


I love Nepal and I feel sorry for Nepalis who have to deal with the complexity of their power system. There is quite some technical debt out there. It is also vulnerable and hard to debug. And for those who knows - power-cuts are not exceptional in Kathmandu.


I feel deep respect for people who are brave enough to share their Program Boards with the numerous strings on them. It shows the level of courage and also the depth of organizational debt. It is vulnerable and hard to debug.


Let's look at one more picture I've found:





Can you spot that there is something "wrong" with this board?


In fact every time I see a SAFe Program Board with no strings attached it makes me feel like the guys who made it just didn't get it. There shall be strings highlighting team dependencies otherwise you're doing it all wrong...


See how corrupt this thinking is?


SAFe made us believe dependencies are ought to be. There are always there. They are expected. They need to be well visualized and well managed.


And if there are no dependencies between the teams? Well you guys are not qualified for the scaled agility. You are too small, young, simple, startup-ish. Come back when you're grown! And bring some meters of strings with you.


I'm hung up on this.

Cut Them Loose, Not Hung Up On Them

What I'd like to see happenning on a PI Planning meeting (not after) is the following: after the teams do the initial string exercise, facilitate a workshop to help them try different re-structuring ideas and then repeat the string exercise to see if the dependencies got cut loose. And then repeat until there is a very minimal number of strings left. 


The remaining strings then need to be seen as a serious organizational impediment and to be taken care by management (facilitated by Scrum Masters).


Then it all will make a lot of sense. But visualization by itself doesn't provide a lot of value (although it may feel good).


Here is a great report how one can go about re-forming teams in a self-organized manner.

Write a comment

Comments: 5
  • #1

    Mike K. (Monday, 07 November 2016 18:15)

    I pretty much agree with most statements.
    The one _I_ get hung up with is this assumption: "SAFe made us believe dependencies are ought to be".

    I would say: "SAFe gives us a way to become aware of dependencies we have in our organization."

    SAFe is *not* a one-size-fits-all. It's a very simple framework for scaling up lean-agile product development with a basis that may (or may not) be Scrum, and provides a toolbox to approach many common organizational ailments. Dependency mapping is one of these tools.

    Why would you look for a hammer if you don't need to drive in a nail?

  • #2

    Em Campbell-Pretty (Tuesday, 15 November 2016 20:09)

    Hi Alexey

    Just FYI the phot you lifted from my blog is not actually a SAFe Program
    Board. It is a visualisation created by a train looking to understand a rolling 4 sprint view of capacity - hence no dependencies.

    With respect to the use of SAFe Program Boards, in my experience visualising dependencies in this manner tends to lead to organisations re thinking how their teams and trains are structured. In many cases the Program Board is the first time the organisation has been able to see and understand the level of complexity involved in delivering on its mission.

    Hope this helps

  • #3

    Alexey Krivitsky (Wednesday, 16 November 2016 09:52)

    Hi Em,

    Thanks for posting.

    Visualizing dependencies might be a good thing. What makes it better is doing something useful with the dependencies (system thinking) rather than being proud they are visualized with colorful strings (tool thinking).

    This is what I meant shortly with my post.

    Let me know if you'd like your photo to be removed.


  • #4

    Mark Richards (Wednesday, 23 August 2023 16:33)

    Hi Alexey,

    I think of the red string like the "gloves on the table" from Switch :) I generally set a goal with ARTs that reduction of red string on their board over time is a good sign of evolution .. but sometimes you need the confronting visual to trigger action. The worst one I've ever seen was driven by vendor commercials dictating sub-optimal team structures and reluctance to revisit commercials during the ART launch. By the end of the first PI Planning there was commitment to re-opening the commercial agreements to enable red string reduction. Love the sentiment of the post though.


  • #5

    Steve Pereira (Wednesday, 23 August 2023 18:58)

    Well said! Dependencies should be visualized, shouldn't be managed, should be measured, and need to be aggressively mitigated.

    I think there are few things more impactful on organizational performance than addressing dependencies, and most constraints I encounter in value streams are directly tied to dependencies.