Dependencies on other teams

Irrespective of how much work remains undone at the end of a Sprint, are the team meeting an agreed Sprint Goal and is an increment of release quality being provided?

Daria,

Regarding your suggestions, I would caution against the 1st item.   

You need to ensure that relative estimates are based on complexity and effort, and do not reflect any "lean waste" item such as waiting.   Always have the team base their estimates on their work only, and this will serve to make issues and impediments visible.   You will only hide dysfunction by burying your wait time into higher estimates.

Regarding your 3rd item, it may be prudent to have an external team actually complete a request/dependency before your team takes on their work.   It is up to you how you want to manage this (separate ticket?).   

What has worked well for me in the past is ensuring that my teams do not take any work into their sprints that have external dependencies.   It is part of the team's Definition of Ready (I know, not part of the Scrum Guide, but having such a checklist works for my teams).   On rare occasions, my team will accept items with external dependencies, but only if there is a high assurance that the dependency, and the team's work, can be completed by the end of the sprint.

Perhaps a hybrid of option 2 and 3 can work.   What you do know is that the current situation is not working, so trying nothing is simply not an option, and you should hold your team accountable to come up with ideas to try and improve the situation.

Good luck!

Have you considered if the teams are setup correctly? Would you be able to reduce dependencies if you were able to do the work inside your own team?

@Ian, unfortunately, the answer to both parts of your question is "No". The work gets stuck and we cannot advance towards our goal.

@Timothy, I agree. I was thinking of incorporating the risk itself not the waiting time, e.g. the risk the other team would not be able to complete on time. Usually if we have worked with a team on similar tickets before we are fairly certain they can complete in timely manner. 

I would definitely go with your approach myself - not take any stories with external dependencies or only take them in once dependencies are resolved. 

I think my mind is in the right place but I'm struggling with resistance to change processes encouraged by leadership. I just wanted to have someone else look at the situation.

@Julian, this is definitely one of the main issues I can see. The organisation is set up in such a way that every team is almost always dependent on another team for something or at some point in time. Usually, when the team brings up dependencies on other teams I challenge them on it: are we really dependent? can we complete it on our side? A lot of the times because of the way the infrastructure of the whole product was built we need another team to intervene.

In Scrum, team members personally commit to the goals of the team, and commitment is of course one of the Scrum values. If team members understand that they will have these dependencies and blockages with essential user stories, why are they committing to a Sprint Goal they know they cannot meet? Why aren’t they insisting on having the necessary skills to do the work? Is there a constraint on team self-organization which ought to be challenged?

In Scrum it is not the case that there will “always be stories like that”, because no-one can force work onto a team which they are unable to do. It seems that in this case work is either being pressured onto the team, or there is an organizational constraint on achieving necessary cross-functionality, or members have a lackadaisical idea of personal commitment, or perhaps a bit of all three.

Thank you, Ian. This is exactly the case in this organisation, you know, when everyone thinks they are Agile and are doing Scrum when they are actually not. I am but a single person who understand we need a bigger more global change, however, I do not have full support of an Agile Coach (I have around 3 years experience in a Scrum Master role), therefore, need to address these challenges on my own.  

Especially agree on the "self-organisation" point - we have a very strong team lead who drives a lot of discussions. This is currently hindering our improvements as a team. 

Hello everyone,

I realize this is a rather old post but I just came across it and it piqued my interest since we are struggling with dependencies as well.  We are in the middle of our Agile and DevOps\CICD  Transformation so we do still have quite some dependencies across squads and Tribes.  

We have our teams and POs try to manage them and when things are really stuck, we have Road Managers (cross-tribe Coordinators) who try to help and lastly an escalation path via our Tribe Leads...  Not elegant but it helps until we finish our transformation...

 One of the conversations we have most frequently is around when dependencies which are known at time of quarterly planning do not materialize and our teams are not able to deliver the Key Results (OKR) to which they committed before end of quarter.  Today we explain that the squad who committed to the deliverable remains responsible and their OKR scoring subsequently should reflect this.  As you can imagine there are varying opinions on this approach with our squads mostly feeling that they should not be penalized for a dependency outside of their squad and which they tried to (unsuccessfully) influence it to be completed.

My question is, ‘Who is accountable for undelivered commitments for which dependencies did not materialize?  What is the industry best practice on this and\or what is the experience of everyone here?  

 

Many thanks in advance!

Scott Jenkins

What commitment have executives made to implement Scrum in the enterprise, and to mitigate organizational impediments? Where is their demonstration of servant-leadership here?