I don't know how helpful this will be, and to some extent I'm reading
between the lines of your message, but I hope it's useful.
"external dependencies...[not] as responsive as the core team"
This is normal in a mixed environment (some agile teams, mostly
traditional organization). As I see it, the main effect of the
situation is that the "last responsible moment" is pulled forward for
taking decisions/actions with respect to the items on which you have
dependencies. That is, if an external group requires 6 weeks to
respond to the core team's request, then the core team has to finalize
the information they need from that external group 6 weeks earlier
than would be the case in an "ideal" agile environment.
A second way to mitigate the effects of the situation is to run your
demonstrations in a sandbox of your own making. That is, mask off or
"stub" or "mock" or "simulate" external interfaces. Your customer may
claim that there's no real business value until all the external
interfaces are live, and they're right at a certain level, but your
main goal is to demonstrate the code the core team has written, and
not (necessarily) to demonstrate the external dependencies. (Of
course, there may be sprints in which connectivity with external
systems is specifically what you want to demonstrate, but that's a
A third way is to try and engage the external groups on which you have
dependencies as early as possible in the project and help them
understand what you are trying to do, and how your methods differ from
what has gone before in the organization. I've found three different
reactions from traditional IT groups when taking this approach: (a)
They like the idea because they are just as fed up with the status quo
as we are; (b) they aren't excited about it but they are willing to
modify their standard procedures to try and get results to your team
faster than they normally do; or (c) they tell us to get lost and
follow the standard procedures. You may be able to solve or mitigate
at least part of the problem this way.
"Do I cancel the retrospective/showcase..."
I would vote "no" to this idea, because the retrospective and showcase
provide an excellent opportunity to demonstrate the effects of the
organizational problem in front of key stakeholders. During the
retrospective, the team and stakeholders may be able to arrive at some
sort of corrective action. Some of the stakeholders may have more
influence in the organization than the core team has, and they may be
able to help.
"My team has been working around the clock..."
Okay, well, stop doing that. Just work normal hours. You can't fix
organizational dysfunction by working excessive overtime. The amount
of work the team can complete by working at a sustainable pace is
realistically the amount of work that can be accomplished. I think
it's better to expose the true root causes of the issues and address
those, rather than to try and compensate for organizational problems
by working more hours.
"Mentioned we failed to complete a sprint? Continue the sprint?"
I don't think the word "failure" is very constructive. You set some
goals, you tried to meet them, and you achieved some positive outcomes
and some negative outcomes. The point is to learn from what happened,
both positive and negative, and stay focused on the project's overall
goals and on continuous improvement in the team's effectiveness. My
vote is to let the sprint end on schedule and conduct all the normal
sprint-end activities as per usual. If the results are less than
hoped-for, then explore the reasons why and take corrective action
--- In firstname.lastname@example.org
> Has your team ever failed a sprint?
> My current team is working on a sprint right now which has a lot of
> external dependencies. The external dependencies are beyond our
> control and due to resources not directly on the team, they haven't
> been as responsive as the core team. My team has been working around
> the clock but the external dependency has taken a sour toll on this
> current sprint. Our sprint ends tomorrow and we have our feature
> showcase and retrospective scheduled.
> What is the message I send to the team? Do I cancel the
> retrospective/showcase and wait for the sprint to complete? Mentioned
> we failed to complete a sprint? Continue the sprint?
> This has never happened before :( Help!