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

Many small projects

Expand Messages
  • msbscrum
    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
    Message 1 of 8 , Nov 1, 2005
    • 0 Attachment
      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?
    • Koscho, William
      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
      Message 2 of 8 , Nov 1, 2005
      • 0 Attachment

        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?







        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.

      • 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 3 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 4 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 5 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 6 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 7 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 8 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.