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

Agile/Scrum in Matrix structure

Expand Messages
  • Ada Gurman
    Does anyone have experience and lessons learned in implementing Agile in Matrix organization? ________________________________ From:
    Message 1 of 10 , Apr 1, 2008
    • 0 Attachment

      Does anyone have  experience and lessons learned in implementing Agile in Matrix organization?

       

       


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of brett_a_bernstein
      Sent: Tuesday, April 01, 2008 3:05 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: dealing with emergencies

       

      One of the challenges for any scrummaster/ scrum team is how to deal
      with something that it outside the scope of the sprint backlog. It
      represents 'change' and I always found myself reminding my teams (a)
      that change is inevitable and (b) that scrum in part is designed to
      handle change.

      That having been said, I also tried to get the PO to do some up-front
      evaluation of the item. We were running 2 weeks sprints so if it came
      up in the middle of a sprint, on average, the soonest it could get
      finished would be the end of the next sprint in about 3 weeks

      [note: this assumes the item is small enough to do in a single sprint;
      we sometimes would devote 5-10 min after the daily stand to *briefly*
      discuss the item to determine this.]

      [note #2: the whole 1.5 x sprint length idea came from something I
      read written by Mike Cohn. If Mike had a dollar for every time I
      quoted that he would be a very, very happy camper. :)]

      The questions I asked were:

      To the team: 'Can this item be incorporated into the sprint commitment
      without giving up anything else?' If the item was small enough, the
      team usually had no issues. The key was asking the question in such a
      way that wasn't interpreted as an interruption (hence the 5-10 minute
      timebox). If it needed more then 5-10 minutes, odds are good it
      wasn't going to be something that could be slipped in.

      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.

      Side note ... this team had a good working relationship with its PO
      most of the time, but was confident enough in its abilities to push
      back when necessary.

      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.

      So my advice on your original question (how to deal with emergencies) is:

      a) try to shift the conversation around when the PO brings up an
      emergency. See what the team thinks about it (minimal time
      investment) and see if it really is a firedrill or if it is simply
      something that someone wants, but can wait till the next sprint for

      b) during retrospective look at the set of emergency items that came
      up and see if there are patterns. You might want to put in a user
      story that would help address some of those emergency items so the
      business unit can solve them without involving the implementation team
      directly. We got a lot of mileage out of this question and were able
      to eliminate certain items that previously had been 'emergencies'

      I freely admit that this approach violates the reciprocal commitments,
      but it was my attempt to balance the legit needs of the business vs.
      the legit needs of the team.

      Good Luck,

      Brett

      --- In scrumdevelopment@ yahoogroups. com, "Pascal Thivent" <pascal@...>
      wrote:

      >
      > I agree, the biggest problem I see is that you (or the PO )
      are
      changing the
      > scope of the Sprint during the sprint and this is not recommended.
      >
      > If you or the PO think these emergency
      tasks will raise regularly, I
      would
      > suggest to allocate some time for "production support" in each
      sprint and
      > create an item (with story point estimate) in each sprint backlog.
      Use then
      > this allocated time if emergency problem occur in production and add
      tasks
      > (in hours) for them in the Sprint Backlog. If you don't need this
      time, just
      > use it to fix the production code to avoid having emergency problems
      - or
      > take an additional item from the Product Backlog. This way, your
      velocity
      > will be more stable and facilitate the PO
      work (having the velocity
      going
      > down because of impediments is not an issue in itself, the
      impediments are
      > the issue).
      >
      > Having written this, I'm realizing there aren't much differences (taking
      > items and removing some of them because of unplanned tasks VS taking
      items
      > and some "optional" one if no unplanned tasks raise) and I feel
      a
      bit like
      > changing the scope in both case. But still, I believe the second option
      > would be better.
      >
      > WDYT ?
      > On Mon, Mar 31, 2008 at 2:42 AM, jurgendesmet <jurgendesmet@ ...>
      > wrote:
      >
      > > --- In
      scrumdevelopment@ yahoogroups. com<scrumdevelopment% 40yahoogroups. com>,
      > > "Filipe Melo"
      > > <filipe.guelber@ > wrote:
      > > >
      > > > Im my company im a ScrumMaster and we are in Sprint #3, the
      duration
      > > > of our sprints is 2 weeks.
      > > > We work in a critical system already in production and sometimes
      some
      > > > bugs or changes are required during the sprint. Which one are
      > > > prioritised by PO before the
      actual user stories in the current
      > > > sprint. In this case is imperative to us stop the current task
      and
      > > > starts to working in emergencial change. My question is: How I
      deal
      > > > with this emergencial tasks ? Nowadays I work in emergencial
      tasks and
      > > > obviously i need to remove some story from the sprint backlog,
      but
      > > > working in this way my velocity (in user story points) go down.
      Is
      > > > correct add this changes "on the fly" in the sprint
      backlog and
      > > > estimates points to it ? Or I should keep working in this way ?
      > > > thanks !
      > > >
      > > > --
      > > > Filipe
      > > > "Programming today is a race between software engineers
      striving to
      > > > build bigger and better idiot-proof programs, and the Universe
      trying
      > > > to produce bigger and better idiots. So far, the Universe is
      winning."
      > > > Rich Cook
      > > >
      > >
      > > What you are actually saying is that you have to deal with
      > > impediments, it is normal that impediments bring down the teams
      > > velocity and thus your way of working is correct. That's just one of
      > > the clues of using scrum: making things visible that go wrong and
      take
      > > action to improve. You can use the burndown charts and dropping team
      > > velocity to show why you take action to avoid impediments in the
      future.
      > >
      > > Basically since you're working with short cycles "changes"
      as you call
      > > them should go by default into the next sprint and not disturb the
      > > ongoing work. If changes get in during the sprint this most probably
      > > points out that your product owner should do a better job and that
      you
      > > as a scrum master should come into the picture to put a hold on it.
      > > Also try to bring in your end users into the picture of developing
      new
      > > products, they will understand how it works and feel much comfortable
      > > at the end.
      > >
      > > Bugs are something different, these should indeed always be taken up
      > > asap after reconciliation by the PO .
      These will also bring down the
      > > teams velocity and there the impediment you have to handle is:
      > > quality. Best things to do in this case according to my experience is
      > > adding some of the XP techniques. As soon as quality is improving
      also
      > > this impediment will be less involved in your teams velocity and thus
      > > improve your process to deliver.
      > >
      > > Hope this was what you're looking for and I'm also looking forward to
      > > see how others deal with this. Definatly a topic to check out later
      on
      > > when there's more response.
      > >
      > >
      > >
      >
      >
      >
      > --
      > Pascal
      >

    • Dmitry Beransky
      On Tue, Apr 1, 2008 at 12:05 PM, brett_a_bernstein ... To Brett, or anyone else who can answer. I m still shaky on this whole notion of interrupting a sprint.
      Message 2 of 10 , Apr 1, 2008
      • 0 Attachment
        On Tue, Apr 1, 2008 at 12:05 PM, brett_a_bernstein
        <brett.a.bernstein@...> 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
      • Tom Hume
        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.
        Message 3 of 10 , Apr 1, 2008
        • 0 Attachment
          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
        • 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 4 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 5 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 6 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.