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

RE: [scrumdevelopment] SCRUM development in a multi-task environm ent

Expand Messages
  • Leesa Haslam
    Hi, You are correct in stating that one of the benefits of scrum is creating a focused environment for the team which allows them to do the most important
    Message 1 of 3 , Nov 30, 2000
    • 0 Attachment
      Hi,

      You are correct in stating that one of the benefits of scrum is creating a
      focused environment for the team which allows them to do the most important
      thing and shields them from "chaos". So what can you do when "chaos" is the
      norm? Here are some ideas:

      - Decide what are the most important projects/tasks to accomplish. In other
      words, what absolutely must be done and done well? Do those things and let
      everything else fall off the plate. If you are having this problem you
      probably have much more that you can ever possible get done on your list
      anyway...

      - Create separate scrums for separate projects. Caution - if you find that
      people are involved in multiple scrums per day you may encounter resistance
      - "too much meeting time", in that case, see my next suggestion.

      - Have a single scrum that sets weekly goals for progressing all projects
      according to need and priority. The decision is made jointly how much
      time/effort to allocate to each project.

      My observation is that people are maximally productive when they are focused
      clearly on a single high priority project. The more context switching
      people are required to do, the less productive they become, doing the
      context switch consumes too much time and energy.

      Good luck!
      -Leesa

      -----Original Message-----
      From: spy [mailto:thespywhocame@...]
      Sent: Wednesday, November 29, 2000 4:46 PM
      To: scrumdevelopment@...
      Subject: [scrumdevelopment] SCRUM development in a multi-task
      environment


      I am a project manager that recently started using SCRUM methodology as a
      way of re-energizing and re-focussing my team on the current project.

      I have found I had already been using variations of all of the SCRUM
      techniques, and I was intrigued and excited by the prospect of combining all
      of these techniques in a simple incremental and structured approach to the
      "chaos".

      So far the SCRUM is working out great, however the external chaos seems to
      be creeping back in.

      This is primarily due to the fact that our current organizational structure
      relies too heavily on a multi-project multi-task basis.

      Fundamentally I see SCRUM as a single project methodology only. I see the
      primary driving force behind the methodology is the focussing of team effort
      shielding the team from the "chaos"

      I my situation where "chaos" comes in the form of multiple concurrent
      projects with varying priorities, the SCRUM is starting to fall apart.

      Is there any work on such scenarios or are there alternative methodologies.

      I am thinking of running multiple simultaneous SCRUMS whereby the SPRINT's
      are shortened to reflect the decreased time available due to multitasking,
      however this approach seems contrary to the simplified focussed approach of
      SCRUM.

      Any ideas would be appreciated.


      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
    • Peter McGowan
      Hi, How have you handled documentation personnel in the past? In a perfect world each member of the Scrum team is focused on the same goal, the next release
      Message 2 of 3 , Nov 30, 2000
      • 0 Attachment
        Hi,

        How have you handled documentation personnel in the past? In a perfect world
        each member of the Scrum team is focused on the same goal, the next release of
        the product. However most documentation personnel I have worked with will argue
        that they have very little work during the early stages of a sprint, and have
        too much to do in the later stages. It is nearly impossible to time-slice such
        individuals across Scrum teams since this would require that the sprints overlap
        perfectly. Any advice?

        The big advantage of involving them in the complete sprint is that they will
        constantly be "on the same page" as the rest of the team, and oft times
        engineers will produce better designs when they have to explain them on a
        regular basis (the person listening doesn't necessarily have to understand, the
        point is to force the engineer to see improvements). I'm considering having
        documentation take care of producing the design documentation directly, rather
        than relying on the principles and architects. This should free up engineering,
        but will require increasing documentation. It also requires technically savvy
        authors, but I recall this used to be a problem with QA when they became
        involving in the early stages of development.

        Has anyone tried this solution?


        -Peter


        ----- Original Message -----
        From: "Leesa Haslam" <Leesa.Haslam@...>
        To: <scrumdevelopment@egroups.com>
        Sent: Thursday, November 30, 2000 4:22 PM
        Subject: RE: [scrumdevelopment] SCRUM development in a multi-task environm ent


        > Hi,
        >
        > You are correct in stating that one of the benefits of scrum is creating a
        > focused environment for the team which allows them to do the most important
        > thing and shields them from "chaos". So what can you do when "chaos" is the
        > norm? Here are some ideas:
        >
        > - Decide what are the most important projects/tasks to accomplish. In other
        > words, what absolutely must be done and done well? Do those things and let
        > everything else fall off the plate. If you are having this problem you
        > probably have much more that you can ever possible get done on your list
        > anyway...
        >
        > - Create separate scrums for separate projects. Caution - if you find that
        > people are involved in multiple scrums per day you may encounter resistance
        > - "too much meeting time", in that case, see my next suggestion.
        >
        > - Have a single scrum that sets weekly goals for progressing all projects
        > according to need and priority. The decision is made jointly how much
        > time/effort to allocate to each project.
        >
        > My observation is that people are maximally productive when they are focused
        > clearly on a single high priority project. The more context switching
        > people are required to do, the less productive they become, doing the
        > context switch consumes too much time and energy.
        >
        > Good luck!
        > -Leesa
        >
        > -----Original Message-----
        > From: spy [mailto:thespywhocame@...]
        > Sent: Wednesday, November 29, 2000 4:46 PM
        > To: scrumdevelopment@...
        > Subject: [scrumdevelopment] SCRUM development in a multi-task
        > environment
        >
        >
        > I am a project manager that recently started using SCRUM methodology as a
        > way of re-energizing and re-focussing my team on the current project.
        >
        > I have found I had already been using variations of all of the SCRUM
        > techniques, and I was intrigued and excited by the prospect of combining all
        > of these techniques in a simple incremental and structured approach to the
        > "chaos".
        >
        > So far the SCRUM is working out great, however the external chaos seems to
        > be creeping back in.
        >
        > This is primarily due to the fact that our current organizational structure
        > relies too heavily on a multi-project multi-task basis.
        >
        > Fundamentally I see SCRUM as a single project methodology only. I see the
        > primary driving force behind the methodology is the focussing of team effort
        > shielding the team from the "chaos"
        >
        > I my situation where "chaos" comes in the form of multiple concurrent
        > projects with varying priorities, the SCRUM is starting to fall apart.
        >
        > Is there any work on such scenarios or are there alternative methodologies.
        >
        > I am thinking of running multiple simultaneous SCRUMS whereby the SPRINT's
        > are shortened to reflect the decreased time available due to multitasking,
        > however this approach seems contrary to the simplified focussed approach of
        > SCRUM.
        >
        > Any ideas would be appreciated.
        >
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        >
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        >
      • Leesa Haslam
        Hi, I ve faced this same dilemma many times. The approach that I ve found works best for me is for the documentation team to assign a single doc person as a
        Message 3 of 3 , Dec 1, 2000
        • 0 Attachment
          Hi,

          I've faced this same dilemma many times. The approach that I've found works
          best for me is for the documentation team to assign a single doc person as a
          liaison to each scrum team. The doc person represents the interest and
          issues of the rest of the doc team and can carry back and disseminate
          information from the scrum to the rest of the doc team.

          I have also struggled with the "how to get design documents and functional
          specs written" dilemma. I've found that having a QA person and an
          Engineering jointly responsible for each document helps tremendously. In my
          experience, the QA person ends up doing most of the writing. This
          collaborative effort gets greater QA participation in the earlier phases and
          drives more detail into the document.

          I've often found it valuable to include a representative from a customer
          facing department in scrums too, for example, a client services, training
          and/or technical support representative. It helps inject customer feedback
          and it helps with the dissemination of information back to those
          departments.

          -Leesa


          -----Original Message-----
          From: Peter McGowan [mailto:mcgowan@...]
          Sent: Thursday, November 30, 2000 10:51 PM
          To: scrumdevelopment@egroups.com
          Subject: Re: [scrumdevelopment] SCRUM development in a multi-task
          environm ent


          Hi,

          How have you handled documentation personnel in the past? In a perfect
          world
          each member of the Scrum team is focused on the same goal, the next release
          of
          the product. However most documentation personnel I have worked with will
          argue
          that they have very little work during the early stages of a sprint, and
          have
          too much to do in the later stages. It is nearly impossible to time-slice
          such
          individuals across Scrum teams since this would require that the sprints
          overlap
          perfectly. Any advice?

          The big advantage of involving them in the complete sprint is that they will
          constantly be "on the same page" as the rest of the team, and oft times
          engineers will produce better designs when they have to explain them on a
          regular basis (the person listening doesn't necessarily have to understand,
          the
          point is to force the engineer to see improvements). I'm considering having
          documentation take care of producing the design documentation directly,
          rather
          than relying on the principles and architects. This should free up
          engineering,
          but will require increasing documentation. It also requires technically
          savvy
          authors, but I recall this used to be a problem with QA when they became
          involving in the early stages of development.

          Has anyone tried this solution?


          -Peter


          ----- Original Message -----
          From: "Leesa Haslam" <Leesa.Haslam@...>
          To: <scrumdevelopment@egroups.com>
          Sent: Thursday, November 30, 2000 4:22 PM
          Subject: RE: [scrumdevelopment] SCRUM development in a multi-task environm
          ent


          > Hi,
          >
          > You are correct in stating that one of the benefits of scrum is creating a
          > focused environment for the team which allows them to do the most
          important
          > thing and shields them from "chaos". So what can you do when "chaos" is
          the
          > norm? Here are some ideas:
          >
          > - Decide what are the most important projects/tasks to accomplish. In
          other
          > words, what absolutely must be done and done well? Do those things and
          let
          > everything else fall off the plate. If you are having this problem you
          > probably have much more that you can ever possible get done on your list
          > anyway...
          >
          > - Create separate scrums for separate projects. Caution - if you find that
          > people are involved in multiple scrums per day you may encounter
          resistance
          > - "too much meeting time", in that case, see my next suggestion.
          >
          > - Have a single scrum that sets weekly goals for progressing all projects
          > according to need and priority. The decision is made jointly how much
          > time/effort to allocate to each project.
          >
          > My observation is that people are maximally productive when they are
          focused
          > clearly on a single high priority project. The more context switching
          > people are required to do, the less productive they become, doing the
          > context switch consumes too much time and energy.
          >
          > Good luck!
          > -Leesa
          >
          > -----Original Message-----
          > From: spy [mailto:thespywhocame@...]
          > Sent: Wednesday, November 29, 2000 4:46 PM
          > To: scrumdevelopment@...
          > Subject: [scrumdevelopment] SCRUM development in a multi-task
          > environment
          >
          >
          > I am a project manager that recently started using SCRUM methodology as a
          > way of re-energizing and re-focussing my team on the current project.
          >
          > I have found I had already been using variations of all of the SCRUM
          > techniques, and I was intrigued and excited by the prospect of combining
          all
          > of these techniques in a simple incremental and structured approach to the
          > "chaos".
          >
          > So far the SCRUM is working out great, however the external chaos seems to
          > be creeping back in.
          >
          > This is primarily due to the fact that our current organizational
          structure
          > relies too heavily on a multi-project multi-task basis.
          >
          > Fundamentally I see SCRUM as a single project methodology only. I see the
          > primary driving force behind the methodology is the focussing of team
          effort
          > shielding the team from the "chaos"
          >
          > I my situation where "chaos" comes in the form of multiple concurrent
          > projects with varying priorities, the SCRUM is starting to fall apart.
          >
          > Is there any work on such scenarios or are there alternative
          methodologies.
          >
          > I am thinking of running multiple simultaneous SCRUMS whereby the SPRINT's
          > are shortened to reflect the decreased time available due to multitasking,
          > however this approach seems contrary to the simplified focussed approach
          of
          > SCRUM.
          >
          > Any ideas would be appreciated.
          >
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@...
          >
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...
          >



          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...
        Your message has been successfully submitted and would be delivered to recipients shortly.