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

Re: [scrumdevelopment] Many small projects

Expand Messages
  • Laurent Bossavit
    Jason, ... A client of mine faces much the same situation. After some training, and lots of discussion, we came to a tentative conclusion that the best thing
    Message 1 of 8 , Nov 1, 2005
    • 0 Attachment
      Jason,

      > This is difficult as there are developers that need to be involved
      > with simultaneous projects and I can't think of a way to insert a
      > backlog type of style into the process, when teams are sprinting
      > against many projects and prioroties.

      A client of mine faces much the same situation. After some training,
      and lots of discussion, we came to a tentative conclusion that the
      best thing they could do to improve was to work on fewer projects.
      The root problem is that people go faster when they work on fewer
      things at the same time, while multitasking wastes time.

      We agreed that it was a hindrance to taking full advantage of XP-
      style or Scrum-style planning, and that the situation demanded
      management attention. It turns out to be difficult to change when
      you're in that mode, for all sorts of reasons, but that doesn't
      change the diagnosis...

      Cheers,

      -[Laurent]-
      You want to know how to write a perfect program ? It's easy. Make
      yourself perfect and then just code naturally.
      Robert Pirsig (nearly)
    • Ripley, Amy
      I am an agile coach that uses scrum for small enhancements and projects. Our team consists of 14 people that support 12 applications within a larger platform.
      Message 2 of 8 , Nov 1, 2005
      • 0 Attachment
        Message
        I am an agile coach that uses scrum for small enhancements and projects.  Our team consists of 14 people that support 12 applications within a larger platform.  While our developers and testers are cross trained on several systems, each has a particular area where they have significantly more depth of knowledge.
         
        Our process revolves around a queuing system.  We queue up requests that are ready for development and assign a small development team to the request, 2 developers and 1 tester.  We pull prioritized work from our product backlog as we have resources available.  The work is prioritized using a model that has several attributes that determine its priority.  Our customers are involved in this process but we have many customers, one for each request across 12 applications, so we have developed the model in order to remove the subjectivity of priority.
         
        We only pull work into the working queue when there is no current work for that development team.  Our theory is based on focusing on one request at a time and moving it through to implementation rather than working on multiple requests at a time.
         
        This has worked very well for the team and has decreased our cycle time by 4 weeks since implemented agile methodology.
         
        Amy Ripley 
         
        -----Original Message-----
        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of msbscrum
        Sent: Tuesday, November 01, 2005 11:33 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Many small projects

        I posted this a while ago, and didn't get much response so here goes
        again.

        Does anyone have any experience running MANY smaller projects using
        the scrum methodology?  This is difficult as there are developers that
        need to be involved with simultaneous projects and I can;t think of a
        way to insert a backlog type of style into the process, when teams are
        sprinting against many projects and prioroties.

        Any advice?





      • kane_sfo
        ... This sounds like a terrific adapation. I d love to hear more details about this (specifically what attributes you re considering, how do you balance the
        Message 3 of 8 , Nov 1, 2005
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, "Ripley, Amy"
          <amy.ripley@c...> wrote:
          > The work is prioritized
          > using a model that has several attributes that determine its priority.
          > Our customers are involved in this process but we have many customers,
          > one for each request across 12 applications, so we have developed the
          > model in order to remove the subjectivity of priority.

          This sounds like a terrific adapation. I'd love to hear more details
          about this (specifically what attributes you're considering, how do
          you balance the different attributes, how/if you negotiate between the
          different parties etc).

          Best regards,
          Kane Mar
          --------
          U: http://www.danube.com/
          E: Kane at Danube dot com
        • Ripley, Amy
          The model has attributes that are weighted. Key attributes are customer impact (actual Capital One cardholder customers), system impact, number of systems
          Message 4 of 8 , Nov 1, 2005
          • 0 Attachment
            Message
            The model has attributes that are weighted.  Key attributes are customer impact (actual Capital One cardholder customers), system impact, number of systems impacted, is there a work-around, is this a revenue generating request, is the request legal, audit or compliance.  Each attribute is weighted according to importance to Capital One imperatives, goals, and operating procedures.  A group of key individuals helped to develop the model and we have added several attributes over the last few months.
             
            We do have to negotiate between parties on occasion.  Because we have such a strong team of individuals across many applications, it is rare that we only have capacity for one request over another.  When we do, we pull the customers into a room and discuss the impacts of each request and have the customers work out what the team should work on first.  We do what we can to stay out of determining priority.  Sometimes this means bringing in VPs of lines of business but we feel it is important for our customers to work together to determine what we should work on next if there is a conflict. 
             
            Amy
            -----Original Message-----
            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of kane_sfo
            Sent: Tuesday, November 01, 2005 1:48 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Re: Many small projects

            --- In scrumdevelopment@yahoogroups.com, "Ripley, Amy"
            <amy.ripley@c...> wrote:
            > The work is prioritized
            > using a model that has several attributes that determine its priority.
            > Our customers are involved in this process but we have many customers,
            > one for each request across 12 applications, so we have developed the
            > model in order to remove the subjectivity of priority.

            This sounds like a terrific adapation. I'd love to hear more details
            about this (specifically what attributes you're considering, how do
            you balance the different attributes, how/if you negotiate between the
            different parties etc).

            Best regards,
            Kane Mar
            --------
            U: http://www.danube.com/
            E: Kane at Danube dot com 





          • Wim van de Goor
            ... In our organization we use Scrum for all projects. Most projects take a year or more. However, we regularly get requests that only take a few days to a
            Message 5 of 8 , Nov 2, 2005
            • 0 Attachment
              msbscrum wrote:
              > Does anyone have any experience running MANY smaller projects using
              > the scrum methodology? This is difficult as there are developers that
              > need to be involved with simultaneous projects and I can;t think of a
              > way to insert a backlog type of style into the process, when teams are
              > sprinting against many projects and prioroties.
              >
              > Any advice?
              >

              In our organization we use Scrum for all projects. Most projects take a year or
              more. However, we regularly get requests that only take a few days to a couple
              of weeks and which don't have a high priority (it doesn't have to be ready
              tomorrow). We have a special team for handling these requests.

              At the moment this team works on 4 projects. The team makes a grid of who works
              on which day part (morning/ afternoon) on which project. This takes away most of
              the pain of task (and context) switching. The schedule can also ensure that two
              people work at the same project at the same time to enable pair programming.

              Each project has its own product owner. They have seperate meetings with each
              customer/product owner for progress and iteration planning. Of course these
              meetings do not take half a day per project.

              The reason to have this team work on more projects is to have a TEAM with people
              that can help each other.

              Wim.
            • poppy_martono
              Hi jason, This is exactly the same problem I have a while ago. 1 person = many projects is a common culture here :) I tried to execute this process: - split
              Message 6 of 8 , Nov 2, 2005
              • 0 Attachment
                Hi jason,

                This is exactly the same problem I have a while ago. 1 person = many
                projects is a common culture here :)
                I tried to execute this process:
                - split the project into small scrum team (independent), 1 person can
                be in many teams, but then has his/her own task list for 7 hrs/day
                - once a week we have a large scrum meeting, where the scrum masters
                report the progress / talk abt problem / knowledge transfer, etc
                - internal scrum management is completely managed by the team (we have
                central product backlog, but we expect each team to be self-managed,
                as the team is very small - only 3-4 people each)
                - establish intranet project board (burn down charts displays) where
                the managers can see the progress for all projects
                - more frequent code review (peer review)

                William's advice is valid though, now we tried to focus at least one
                or two person to one project, even though it's still very hard to
                achieve as we have a lot of high priority maintenance/change requests.
                Support/maintenance also run as one scrum project.

                It was a real headache before we have this process in place. But now,
                it's working like a charm!!

                --- In scrumdevelopment@yahoogroups.com, "Koscho, William"
                <william_koscho@m...> wrote:
                >
                > When you say "smaller" teams, how many people do you have per team?
                >
                >
                >
                > You could try reorganizing...it sounds like you have resources
                spread thin
                > over several projects.
                >
                > Instead you may reduce the number of resources on each team and make
                them
                > 100% dedicated to that team.
                >
                >
                >
                > Ideally you would like to have your resources focused on a single
                project to
                > be most productive. Try to see why you cannot achieve that. Is it
                because
                > you have only a few Subject Matter Experts, or because you don't
                have enough
                > resources, or your business/management are giving you other types of
                > constraints to work within?
                >
                >
                >
                >
                >
                >
                >
                >
                >
                > -----Original Message-----
                > From: scrumdevelopment@yahoogroups.com
                > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of msbscrum
                > Sent: Tuesday, November 01, 2005 11:33 AM
                > To: scrumdevelopment@yahoogroups.com
                > Subject: [scrumdevelopment] Many small projects
                >
                >
                >
                > I posted this a while ago, and didn't get much response so here goes
                > again.
                >
                > Does anyone have any experience running MANY smaller projects using
                > the scrum methodology? This is difficult as there are developers that
                > need to be involved with simultaneous projects and I can;t think of a
                > way to insert a backlog type of style into the process, when teams are
                > sprinting against many projects and prioroties.
                >
                > Any advice?
                >
                >
                >
                >
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@e...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@e...
                >
                >
                >
                >
                > _____
                >
                > YAHOO! GROUPS LINKS
                >
                >
                >
                > * Visit your group "scrumdevelopment
                > <http://groups.yahoo.com/group/scrumdevelopment> " on the web.
                >
                >
                > * To unsubscribe from this group, send an email to:
                > scrumdevelopment-unsubscribe@yahoogroups.com
                >
                <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                >
                >
                > * Your use of Yahoo! Groups is subject to the Yahoo!
                > <http://docs.yahoo.com/info/terms/> Terms of Service.
                >
                >
                >
                > _____
                >
                >
                >
                >
                > -----------------------------------------
                > This e-mail message and any attachments contain confidential
                > information from Medco. If you are not the intended recipient, you are
                > hereby notified that disclosure, printing, copying, distribution, or
                > the taking of any action in reliance on the contents of this electronic
                > information is strictly prohibited. If you have received this e-mail
                > message in error, please immediately notify the sender by reply message
                > and then delete the electronic message and any attachments.
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.