Dependencies between teams in Scrum

Hi Jason,

My opinion and understanding is 2) have clear requirements. Clear requirements in Scrum means well defined product backlog items. If the backup items are properly defined, each Scrum Team will select independent Backlog items into their Sprint Backlog. Therefore there should not be dependencies when requirements are clear. 

Best regards,

Mein Sin

My preferred option is "reduce dependencies" but it doesn't always work. 

Your theory seems right to me.  But the real life problem is that you can't always identify all dependencies. It is frequent that while doing work you will uncover something you didn't expect and those can be dependencies.  So, I coach to identify everything you can before during refinement and discuss mitigation plans.  If there is absolutely no way that the team can deal with the dependency on their own, then cross team discussions and necessary coordination must ensue.  But I really encourage my teams to find ways of dealing with a "dependency" on their own.  Is this a dependency in code where the "other team" needs to do the work?  If so, why can't my team do the work and have someone from the other team review it?  That way you aren't waiting on another team to be able to fit the code changes into their sprint before my team can start working.  There are many ways to address dependencies and not all of them require waiting on someone else. This aligns with the "reduce dependencies" philosophy, at least to me. 

Reason I don't agree with the "clear requirements" answer is because the idea behind agile is to be able to work without complete requirements and adapt as deliver increments of value.  Trying to identify clear requirements seems very waterfall-ish to me and reminds me of the days where I had to "test" 100 page requirement documents.  If the answer had been "clear enough to begin work requirements" I might agree.  But as stated, "reduce dependencies" is my answer. 

a question about how to efficiently coordonate teams working on a single product.

I’m not sure that teams would be co-ordinated, at least not in the sense of co-ordination being something done to them. Rather, co-ordination ought to be facilitated. A significant part of self organization involves teams reducing dependencies of various kinds. If the requirements are clear enough to allow this to be done efficiently, so that the work is understood and may be taken on, then perhaps that is good enough.

Thank you for your kind and always very instructive answers. Knowledge and experience sharing here is always of great help.

In my point of view, and I agree with you Daniel,  "clear requirements" sounds a lot like good old  Big Design UpFront classical trap and I am not a big fan of this answer. On an other point of vue, there should not exist dependencies as Mein Sin said, and so "reducing dependencies" also sounds like a "not so good" answer.

More importantly, coaching "to identify everything you can before during refinement and discuss mitigation plans" (Daniel) seems to me as a key concern, thanks for the guideline!

J.