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

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

Expand Messages
  • 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 1 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 2 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.