5863Re: Multi-Project Development with Limited Resources
- Jan 3, 2005Hi Mike,
Thanks for the pointer. Some questions that I have:
1. What do is the difference between a Shared Resources Scrum Master
and a 'normal' (is there anyone normal among us ;-) ) Scrum Master?
2. What do you mean by 'Production Super Sprints'?
3. Would be intersting to hear, how you do this in the concrete
-> Integration Testing across applications and reusable components?
(Btw: What happend to XBreed?)
--- In email@example.com, "Mike Beedle" <beedlem@e...>
> I unfortunately haven't made time to write more about running Scrum for
> multiple projects, but here are some things we do:
> - Mike
> -----Original Message-----
> From: jiri_lundak [mailto:jiri.lundak@l...]
> Sent: Monday, December 27, 2004 6:03 PM
> To: firstname.lastname@example.org
> Subject: [scrumdevelopment] Multi-Project Development with Limited
> 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
> 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
> 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:
> Yahoo! Groups Links
- << Previous post in topic Next post in topic >>