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

5858Re: Multi-Project Development with Limited Resources

Expand Messages
  • Jiri Lundak
    Jan 3, 2005
    • 0 Attachment
      Paul,

      > A different way to look at the issue of multiple concurrent projects
      > with limited resources (a universal phenomenon) is to use a 'portfolio
      > management' concept.

      Interesting perspective. A pre-requisit would be that there is
      something like a strategy in the company. It maybe is more difficult
      to build a portfolio, when the only business strategy is to to make
      money (somehow). ;-)

      Jiri

      --- In scrumdevelopment@yahoogroups.com, "Royer, Paul" <proyer@c...>
      wrote:
      > A different way to look at the issue of multiple concurrent projects
      > with limited resources (a universal phenomenon) is to use a 'portfolio
      > management' concept. This idea ties projects (any kind, not just IT) to
      > the business strategy of the organization. It's aim is to force the
      > alignment of project requests with business objectives; thus, leading to
      > a global prioritization of projects. Then, in addition to the Product
      > and Sprint Backlogs; one could now envision a Portfolio Backlog to be
      > reconciled once or twice a year when budget planning is done. I think
      > the analogy fits and can be extended throughout the Scrum philosophy.
      >
      > Comments and alternate ideas are more than welcomed.
      >
      > Paul S. Royer, PMP
      > Director of Delivery
      > CIBER, Inc.
      > (425)284-1316 office
      > (360)970-9655 mobile
      > PRoyer@C...
      >
      >
      >
      > ________________________________
      >
      > From: jiri_lundak [mailto:jiri.lundak@l...]
      > Sent: Monday, December 27, 2004 4:03 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: [scrumdevelopment] Multi-Project Development with Limited
      > Resources
      >
      >
      >
      > All,
      >
      > Our company does custom project development for different customers.
      > We are involved currently in a major project for one customer (volume
      > of about 14 man years of work) and at the same time there pop up on a
      > regular basis smaller projects of (1 - 3 months), with existing
      > customers.
      >
      > The big project absorbs most of our limited resources. All ten people
      > are needed in the project (also in the interest of sharing knowledge).
      >
      > How can we with our ten people handle multiple projects at the same
      > time?
      >
      > Upper management currently had the dendency to assign to individual
      > developers additionally some other project. Result: The developer was
      > constantly working overtime, practically having to do the smaller
      > project in his spare time, which led to distraction and poor quality
      > in both projects.
      >
      > I was thinking along the lines of trying to convince upper management
      > to switch from a individual project development perspective to a
      > common product development perspective (especially because the code
      > base for all customers should be shared).
      >
      > Can it be, that one can fuel one Sprint backlog with multiple Product
      > backlogs, in the form:
      >
      > Customer A Product Backlog ---
      > \
      > Customer B Product Backlog ------> Sprint Backlog --> Common Incrment
      > /
      > Customer C Product Backlog ---
      >
      > The common increment would deliver to each customer the product
      > (naturally configured for him) once a month.
      >
      > The product managers for the three customers would have to decide
      > at the beginning of each Sprint, how much weight its customer's
      > Product backlog gets in the Sprint.
      >
      > Another possible solution would be to create two teams. The one
      > being there for the big customer and the other one for all the
      > small ones. This would give the main team the possibility to focus
      > on its work. On the other hand there would be an undesirable
      > separation between the teams.
      >
      > Any other approaches you can come up with? Pros and cons? What is the
      > approach that gets us a sustainable pace?
      >
      > Thanks for your thoughts on this subject.
      >
      > Jiri Lundak, CSM, Switzerland.
      >
      >
      >
      >
      >
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@e...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@e...
      >
      >
      >
      > Yahoo! Groups Sponsor
      > ADVERTISEMENT
      > click here
      > <http://us.ard.yahoo.com/SIG=129a4ndps/M=298184.5639630.6699735.3001176/
      > D=groups/S=1707209021:HM/EXP=1104278622/A=2495208/R=0/SIG=11egg01lg/*htt
      > p://www.netflix.com/Default?mqso=60188914>
      >
      > <http://us.adserver.yahoo.com/l?M=298184.5639630.6699735.3001176/D=group
      > s/S=:HM/A=2495208/rand=364617446>
      >
      > ________________________________
      >
      > Yahoo! Groups Links
      >
      >
      > * To visit your group on the web, go to:
      > http://groups.yahoo.com/group/scrumdevelopment/
      >
      > * 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! Terms of
      > Service <http://docs.yahoo.com/info/terms/> .
    • Show all 29 messages in this topic