Loading ...
Sorry, an error occurred while loading the content.

Re: Failed Sprint?

Expand Messages
  • davenicolette
    Hi Khanna, 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
    Message 1 of 8 , Jul 29 5:26 AM
      Hi Khanna,

      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
      different issue.)

      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
      going forward.


      --- In scrumdevelopment@yahoogroups.com, "khanna_angela"
      <khanna_angela@...> wrote:
      > 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!
    Your message has been successfully submitted and would be delivered to recipients shortly.