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

Re: [XP] Running many projects in parallel

Expand Messages
  • Don Wells
    From: Alain Ravet ... Yes, you have identified the hard part. Everyone must be willing to listen and understand the priorities of
    Message 1 of 67 , Dec 2, 2001
      From: "Alain Ravet" <aravet@...>
      > > ..Each project contributes a list of tasks to the group. Based
      > > on what you know about the projects you must then create the
      > > overall priority of the entire list of tasks.
      > Practice sounds less simple than theory.
      > As usual.

      Yes, you have identified the hard part. Everyone must be willing to listen
      and understand the priorities of all the other projects. You must be
      willing to wait to get something done on your own project if another project
      has greater need. This is contrary to most things we are taught by life.

      Don Wells
    • jgoebel@menloinnovations.com
      ... While assigning each individual (or even fixed teams) to work on a single project simplifies some resource management issues, it creates others such as
      Message 67 of 67 , Dec 3, 2001
        > > > One possible precondition .. is that the
        > > > programmers should not be required to divide
        > > > their time too much between various projects
        > > > It interferes with Pair Programming and The
        > > > Planning Game.

        > > For reasons beyond this list scope, this is our daily working
        > > experience :
        > > - n people working on n projects.
        > > - 1 developer per project.
        > > - for many months to 1 year.
        > >
        > > After our current XP pilot project - 3 people, 1 project -,
        > > our 4 man team will receive 4 new
        > > projects, to make succeed in 12-18 months.
        > >
        > > While some have a higher priority, they will all have
        > > to start officially on the 1th of January, and none
        > > can be inactive for too many months at a time
        > > (sounds like "frequent release").
        > >
        > > My colleagues - each responsible of 1 project -
        > > have more or less agreed to work in team,
        > > and use pair programming, if we can figure
        > > out a proper - and convincing : we'll have to
        > > sell this idea to the boss too).- project switching scheme.
        > >
        > > Alain Ravet

        > "Don Wells" <xplist@e...> wrote:
        > What I am working toward is a single team. A single
        > list of tasks to be done. A single team velocity. To get
        > to this I have been working hard to create the single
        > list of tasks.

        While assigning each individual (or even fixed teams) to work on
        a single project simplifies some resource management issues,
        it creates others such as limited expertise and the risk of a
        critical resource loss. It also fails to recognize that most
        projects have uneven resources needs over time.

        After combining several development teams into one and then
        hiring additional staff, the Java Factory team had thirty two
        developers. These developers worked on several projects. To
        accomodate the many sponsors we created some interesting
        tools to augment the planning game. While the Factory team
        differs in size from yours, perhaps you might be able to modify
        some of the techniques for your situation.

        We first assigned each project a color code. Next we calculated
        the total amount of stories that could be completed (we use a
        velocity of 1, but that is another discussion). The total resource
        availability, or the number of stories to be completed, was then
        distributed amoungst the projects. You could simply divide by
        four. We tried to estimate the relative scopes of the projects and
        allocate accordingly, but ultimately this is a management
        decision. We then allocated the available resources to the
        projects on an iteration by iteration basis. This was represented
        by placing colored sheets of paper in a grid.


        Our sheets of paper represented two weeks of stories for one
        pair. So assume that you have eight developers, or four pairs,
        and that the nearest row of paper represents the earliest
        iteration. Then the pattern of paper shown in the jpeg shows an
        arbitrary resource allocation of:

        Iteration One: 4 developers Red, 4 developers Gray
        Iteration Two: 2 Red, 2 Green, 2 Gray, 2 Blue
        Iteration Three: 2 Red, 4 Green, 2 Blue

        The customers for each product would then trade their
        bandwidth to other customers using any rules they wanted. So
        one customer might trade away work this month in exchange for
        extra resources later. But it would be a customer decision. In
        your situation you might not be able to have your customers
        interact, but whoever is managing customer expectations might
        be able to fill in that role.

        But there is no reason to trade available bandwidth unless you
        know what features you can get. So the normal storycard work
        occurs. We then copied the story cards and do planning by
        placing them on the appropriate pieces of colored paper. We
        soon found that we needed a quick way to check everyone's
        math. So we sized the storycards.


        5 x 8 cards represent one week stories. 5 x 8 cards folding in
        half represent half week stories. 8 x 11 sheets of paper
        represent two week stories. Etc, as needed. This is also
        described on page 81 of "Planning Extreme Programming". The
        effort to perform the folding is less than an hour with a hundred
        stories and we found it very worthwhile.

        Customers who need to accelerate the delivery of key features
        and are willing to trade away future bandwidth can negotiate with
        other customers (or their representatives). This can often create
        a win-win scenario. One customer needs more bandwidth while
        the other customer needs early delivery.

        This puts the algorithm for deciding when to introduce context
        changes into the hands of those who can use the decision to
        create business value.

        Completely arbitrary context changes could cause some
        challenges in the development team. The Java Factory team
        dealt with this by being mindful of keeping certain developers
        available to anchor efforts on key projects. But the majority of
        developers would be moved from project to project. This
        movement of developers also created the only case of effective
        cross project code reuse in which I have ever participated. I
        believe this is because the "reuse" was created by individual
        programmers who were working in both code bases and
        understood the true common needs of both projects.

        I would be happy to answer any questions you might have about
        this. We have carried forward this folding of stories and color
        coding technique into all of our new projects even when there is
        only one customer. We simply find it a very powerful
        communication tool.


        In one case, we colorized the story cards themselves to highlight
        how much effort was being expended on "maintenance" stories
        instead of new development. The communication value was
        very powerful, far beyond PowerPoint or any graph. Anyone who
        had an interest in the issue could then walk up and read the
        individual stories.


        James Goebel
        Menlo Innovations
      Your message has been successfully submitted and would be delivered to recipients shortly.