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

Re: Many small projects

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