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

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

Expand Messages
  • 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 1 of 3 , Dec 1, 2000
    View Source
    • 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.