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

5861Re: Multi-Project Development with Limited Resources

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

      Tanks you for your short 'note'.

      Paul has already put together some of the questions on my
      list, so I will only post what addionally pops up in my mind:

      1. What are the metrics you use? What is the 'raw data' one needs for
      producing them?
      2. When do you deploy your 45 releases (does this number concern all
      4 - 6 releases/projects/products) or do you mean you have so many
      releases of each product per year (maybe not very plausible, how
      many customers would like to be updated this frequently, or maybe
      I simple missunderstand, sorry)?
      3. Please define release (= resulting work of one iteration deployed
      to customer?)
      4. Are the code bases (at least partially) shared for all this
      5. Does every developer have to generate some kind of report (you say
      60 sec. per day per developer)? Is this not per team?
      6. How do you synchronize / prioritize the backlogs from different
      7. Do you release your software on an iteration boundary or as this
      seams to be in flux at any one time?
      8. How do you handle branching then (in case you have a common code
      base)? Any particular SCM strategy?
      9. What do you with developers, how do the teams decide for which
      release they would like to work? Along which lines are the teams
      10. How do you resolve conflicting interests within different
      departments? Who decides? The Metascrum team?
      11. How does continuous planning work? Do product owners fuel more
      than one team with backlog items?

      So much for the start.

      Hope these questions can motivate you to expand a bit.
      It will be interesting to read your paper. Let me know
      as soon as you write it.


      --- In scrumdevelopment@yahoogroups.com, "Jeff Sutherland"
      <jeff.sutherland@c...> wrote:
      > At PatientKeeper we have solved the problem of multiple projects
      > pipelined through the same team (or set of teams) and have been
      > running what I call a Type C Scrum or Continuous Scrum for over four
      > years.
      > It requires total automation to do this. However, the data items
      > required are simple and few. The requirement for our developers was
      > less than 60 seconds of overhead a day per developer and less than
      > ten minutes to generate all the reports and graphs management would
      > ever want to see. We have achieved this.
      > Over 45 releases have been delivered to customers this year. What has
      > happened is that it drives the Scrum of Scrums to a daily meeting
      > with a email update right after the meeting that lists the state of
      > all releases (usually 4-6 at any one time). We have what I call a
      > Metascrum that meets weekly with all the leaders from various parts
      > of the company, usually including the CEO. Product management leads
      > the meeting and addresses (1) what got done last week, (2) what got
      > done this week, and (3) what are blocks, changes, damage control
      > strategies that are required.
      > This process has achieved a sustainable pace with many of the same
      > developers working in the same room for over four years with
      > virtually 0% attrition.
      > A more lengthy discussion is beyond the scope of a short note.
      > However, I need to write up a paper on this so if you send me a list
      > of questions that could help generate an outline, it might motivate
      > me to put pen to paper.
      > Jeff Sutherland
      > --- In scrumdevelopment@yahoogroups.com, "jiri_lundak"
      > <jiri.lundak@l...> wrote:
      > >
      > > 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.
    • Show all 29 messages in this topic