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

Re: dealing with emergencies

Expand Messages
  • brett_a_bernstein
    I probably could have provided more detail on the interrupt sprint card ... sorry ... here is a second attempt ... The reciprocal commitments I mentioned in
    Message 1 of 10 , Apr 2, 2008
    • 0 Attachment
      I probably could have provided more detail on the 'interrupt sprint
      card' ... sorry ... here is a second attempt ...

      The reciprocal commitments I mentioned in my last post are pretty
      important IMO to the success of any agile methodology. The team
      commits to a set amount of work. The PO commits to not changing his
      mind about the work he/she requested for the duration of the sprint.
      The value in these dual commitments is that it attempts to eliminate
      what I will call 'interruption-driven-development'. If your team is
      running 4 week sprints and the PO keeps changing his/her mind, then I
      would suggest you consider shorter sprints.

      The card for this team could also be described as 'blow up the current
      sprint' since the PO was basically saying that the sprint backlog as
      defined no longer provided the business value needed at the time. In
      short, if this card was played, the new item was big enough that
      things were going to change more then this one item. I recall this
      card being played only 2-3 times over 2 years and each time it was
      played the explanation as to why it was being played got the
      implementation team on board to re-plan.

      Did this team at times accept swapping-in a new item and swapping-out
      an without fully re-planning? Yes, as I said, we were trying to be
      pragmatic. The key was the brief conversation about the item. If it
      was really small (eg we have new disclaimer copy from the client), it
      wasn't a big deal. I recall this happening in some way/shape/form
      nearly every sprint. Sometimes it was easy. Sometimes there was
      pushback/grumbling.

      Did this always work smoothly? Hell no. I think this is one of the
      tougher day-to-day challenges that SMs face. Did it work better then
      what had happened before we started using scrum? Hell yes.

      To sum things up ...There is a difference between blowing up a sprint
      and giving the PO a helping hand on something. Communication and
      transparency are important. As SM, I was trying to balance the
      legitimate request of the business with the desire o the team to
      finish the work they started. Part of my role was to protect the team
      from outside forces (interruptions) and from itself (not being willing
      to inspect and adapt).



      --- In scrumdevelopment@yahoogroups.com, Tom Hume <Tom.Hume@...> wrote:
      >
      > Out of interest... what would happen is this card were played? Would
      > the PO and the team not gather, replan the sprint exactly as they had
      > before but with A.N. New-Item inserted and another item removed?
      >
      > I get that shifting priorities mid-sprint and/or adding work after the
      > team has committed is bad, but how strong is the disincentive to
      > interrupt the sprint in this case?
      >
      > On 1 Apr 2008, at 21:05, brett_a_bernstein wrote:
      > > The PO also knew that they had the 'interrupt sprint right now' card
      > > in their pocket. He understood the power of this card and how
      > > expensive it was to play. He knew to only pull it out when things hit
      > > the proverbial fan.
      >
      > --
      > Future Platforms Ltd
      > e: Tom.Hume@...
      > t: +44 (0) 1273 819038
      > m: +44 (0) 7971 781422
      > company: www.futureplatforms.com
      > personal: tomhume.org
      >
    • Peter Hundermark
      I agree with Brett s comments. The team is there to do what the PO asks. And when the environment changes, they must adapt, even during the sprint. A good PO
      Message 2 of 10 , Apr 2, 2008
      • 0 Attachment
        I agree with Brett's comments. The team is there to do what the PO asks.
        And when the environment changes, they must adapt, even during the
        sprint. A good PO will minimise the impact by prioritising carefully. A
        good team will improve its process and quality, if this is a
        contributing cause. A good SM will catalyse this.

        Peter
        CSC

        --- In scrumdevelopment@yahoogroups.com, "brett_a_bernstein"
        <brett.a.bernstein@...> wrote:
        >
        > I probably could have provided more detail on the 'interrupt sprint
        > card' ... sorry ... here is a second attempt ...
        >
        > The reciprocal commitments I mentioned in my last post are pretty
        > important IMO to the success of any agile methodology. The team
        > commits to a set amount of work. The PO commits to not changing his
        > mind about the work he/she requested for the duration of the sprint.
        > The value in these dual commitments is that it attempts to eliminate
        > what I will call 'interruption-driven-development'. If your team is
        > running 4 week sprints and the PO keeps changing his/her mind, then I
        > would suggest you consider shorter sprints.
        >
        > The card for this team could also be described as 'blow up the current
        > sprint' since the PO was basically saying that the sprint backlog as
        > defined no longer provided the business value needed at the time. In
        > short, if this card was played, the new item was big enough that
        > things were going to change more then this one item. I recall this
        > card being played only 2-3 times over 2 years and each time it was
        > played the explanation as to why it was being played got the
        > implementation team on board to re-plan.
        >
        > Did this team at times accept swapping-in a new item and swapping-out
        > an without fully re-planning? Yes, as I said, we were trying to be
        > pragmatic. The key was the brief conversation about the item. If it
        > was really small (eg we have new disclaimer copy from the client), it
        > wasn't a big deal. I recall this happening in some way/shape/form
        > nearly every sprint. Sometimes it was easy. Sometimes there was
        > pushback/grumbling.
        >
        > Did this always work smoothly? Hell no. I think this is one of the
        > tougher day-to-day challenges that SMs face. Did it work better then
        > what had happened before we started using scrum? Hell yes.
        >
        > To sum things up ...There is a difference between blowing up a sprint
        > and giving the PO a helping hand on something. Communication and
        > transparency are important. As SM, I was trying to balance the
        > legitimate request of the business with the desire o the team to
        > finish the work they started. Part of my role was to protect the team
        > from outside forces (interruptions) and from itself (not being willing
        > to inspect and adapt).
        >
        >
        >
        > --- In scrumdevelopment@yahoogroups.com, Tom Hume Tom.Hume@ wrote:
        > >
        > > Out of interest... what would happen is this card were played? Would
        > > the PO and the team not gather, replan the sprint exactly as they
        had
        > > before but with A.N. New-Item inserted and another item removed?
        > >
        > > I get that shifting priorities mid-sprint and/or adding work after
        the
        > > team has committed is bad, but how strong is the disincentive to
        > > interrupt the sprint in this case?
        > >
        > > On 1 Apr 2008, at 21:05, brett_a_bernstein wrote:
        > > > The PO also knew that they had the 'interrupt sprint right now'
        card
        > > > in their pocket. He understood the power of this card and how
        > > > expensive it was to play. He knew to only pull it out when things
        hit
        > > > the proverbial fan.
        > >
        > > --
        > > Future Platforms Ltd
        > > e: Tom.Hume@
        > > t: +44 (0) 1273 819038
        > > m: +44 (0) 7971 781422
        > > company: www.futureplatforms.com
        > > personal: tomhume.org
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.