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

RE: [scrumdevelopment] Re: dealing with emergencies

Expand Messages
  • Jaideep Khanduja
    Hi to all, I need some help on redefining my company processes in context to software projects - how agile/scrum would deal with following in relation to team
    Message 1 of 10 , Apr 1, 2008
    • 0 Attachment

      Hi to all,

       

      I need some help on redefining my company processes in context to software projects – how agile/scrum would deal with following in relation to team formation, team size, transparency, story boards, sharing, progress etc.:

      1. business study/ scope freezing/ customer consent/ sign off documents/ team values

      2. product development / sizing/ members/ PO / scrum master/ management/ monitoring/ involvement/ time frame/ progress

      3. testing and QA/QC involvement/ role

      4. implementation/ trainings at customer site (international)/ sign offs

      5. post implementation support

       

      As there are excellent people present on the board (this group), having clear knowledge on the subject, valuable inputs will help me in redefining/ re-engineering/ convincing management to handle these processes.

       

      Issues I am facing right now:

      1. scattered groups
      2. not all concerned are involved
      3. biased/framed/wrong reporting/ projections that effects the complete cycle
      4. person based perceptions/ projections
      5. QA’s role starts at a later stage
      6. improper handling of projects

       

      Best Regards,

       

      Jaideep

      ___________________________________

       

      Thought of the day:  "If you believe that you know the requirements better than the customer, you are part of the problem, not the solution."

      -Alan M. Davis

      ___________________________________

      P Please consider the environment before printing this e-mail


      From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Dmitry Beransky
      Sent: 02 April, 2008 02:38
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: dealing with emergencies

       

      On Tue, Apr 1, 2008 at 12:05 PM , brett_a_bernstein
      <brett.a.bernstein@ gmail.com> wrote:

      > To the PO , assuming that the answer to
      the first question is 'no':
      > 'Can you wait 3 weeks for this or should we interrupt the current
      > sprint?' I found that the good PO can
      explain why he/she can or cannot
      > wait for the item.

      To Brett , or anyone else who can answer. I'm still shaky on this
      whole notion of interrupting a sprint. I understand what purpose it
      theoretically serves, but practically. .. Let's have a hypothetical
      where the new item requires 4 hours to implement. Obviously, it's an
      interruption (disruption) to the sprint. Let's say the PO chooses to
      break the sprint. What exactly does this mean? That we have to sit
      down and estimate this new user story, find an exiting user story in
      the sprint backlog and replace it with the new? So at most this will
      take 3 hours to do (and this is a very generous estimate). Then we'll
      continue the sprint pretty much from where we left off, right?

      All we've lost is 3 hours for replanning. What I don't understand, is
      how this such a horrible thing that is supposed to deter the PO from
      making changes in a middle of a sprint? What am I missing?

      Dmitry

      Confidentiality Notice:

      The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at admin@... immediately and destroy all the copies of this message and any attachments

    • 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 2 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 3 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.