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

Re: Multi-Project Development with Limited Resources

Expand Messages
  • Victor Szalvay
    ... Jeff, I am also interested in type C but don t fully understand how it works. My questions are numerous, but I believe you once told me that work is
    Message 1 of 29 , Jan 2, 2005
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "Jeff Sutherland"
      > 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, I am also interested in type C but don't fully understand how it
      works. My questions are numerous, but I believe you once told me that
      work is "pipelined"; requirements people work one sprint ahead of
      developers and queue work for implementation. My understanding of
      Scrum (at least type B) would indicate that teams are holistic and
      that communication overhead would increase to the detriment of the
      team in this (type C) setup. Clearly this works for you, so how does
      communication work in the pipeline? by artifact?

      Happy New Year everyone!
      -- Victor Szalvay
    • Jean Tabaka
      It has been great following this list over the past year. I look forward to more lively discussion and growth and fun in 2005. Thanks all, Jean _____ From:
      Message 2 of 29 , Jan 2, 2005
      • 0 Attachment

        It has been great following this list over the past year. I look forward to more lively discussion and growth and fun in 2005.

         

        Thanks all,

        Jean

         


        From: Boris Gloger [mailto:boris.gloger@...]
        Sent: Saturday, January 01, 2005 12:52 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] Happy New Year!

         

        Hubert and All,

        Thanks for your friendship, discussions, ideas  and the tremendous
        help during 2004.

        A Happy New Year to you! 

        Boris


        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




      • Balaji C.R
        Hi All: Wishing you all a very Happy New Year. Balaji..CR ... From: Jean Tabaka [mailto:jet@pcisys.net] Sent: Monday, January 03, 2005 8:25 AM To:
        Message 3 of 29 , Jan 2, 2005
        • 0 Attachment
          Hi All:
          Wishing you all a very Happy New Year.
           
          Balaji..CR
          -----Original Message-----
          From: Jean Tabaka [mailto:jet@...]
          Sent: Monday, January 03, 2005 8:25 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] Happy New Year!

          It has been great following this list over the past year. I look forward to more lively discussion and growth and fun in 2005.

           

          Thanks all,

          Jean

           


          From: Boris Gloger [mailto:boris.gloger@...]
          Sent: Saturday, January 01, 2005 12:52 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Happy New Year!

           

          Hubert and All,

          Thanks for your friendship, discussions, ideas  and the tremendous
          help during 2004.

          A Happy New Year to you! 

          Boris


          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...






          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


        • Tobias Mayer
          Me too. This list has been an excellent and exciting source of information, full of interesting connections and glorius Aha! moments. I have learned a great
          Message 4 of 29 , Jan 3, 2005
          • 0 Attachment
            Me too. This list has been an excellent and exciting source of
            information, full of interesting connections and glorius "Aha!"
            moments.

            I have learned a great deal, and hope to be able to give something back
            in 2005 as the organization I work for begins to become receptive to
            Scrum and other Agile principles. Indications are so far good...

            Thank you to everyone who contributed to this list in 2004, and a Happy
            New Year to everyone.

            Tobias


            --- Jean Tabaka <jet@...> wrote:

            > It has been great following this list over the past year. I look
            > forward to
            > more lively discussion and growth and fun in 2005.
            >
            >
            >
            > Thanks all,
            >
            > Jean
            >
            >
            >
            > _____
            >
            > From: Boris Gloger [mailto:boris.gloger@...]
            > Sent: Saturday, January 01, 2005 12:52 AM
            > To: scrumdevelopment@yahoogroups.com
            > Subject: Re: [scrumdevelopment] Happy New Year!
            >
            >
            >
            > Hubert and All,
            >
            > Thanks for your friendship, discussions, ideas and the tremendous
            > help during 2004.
            >
            > A Happy New Year to you!
            >
            > Boris
            >
            >
            > To Post a message, send it to: scrumdevelopment@...
            > To Unsubscribe, send a blank message to:
            > scrumdevelopment-unsubscribe@...
            >
            >
            >
            >
            >
            >
            > Yahoo! Groups Sponsor
            >
            >
            >
            > ADVERTISEMENT
            >
            >
            <http://us.ard.yahoo.com/SIG=129o44cqk/M=295196.4901138.6071305.3001176/D=gr
            >
            oups/S=1707209021:HM/EXP=1104652351/A=2128215/R=0/SIG=10se96mf6/*http:/compa
            > nion.yahoo.com> click here
            >
            >
            >
            >
            <http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=groups/S=
            > :HM/A=2128215/rand=921168600>
            >
            >
            >
            > _____
            >
            > 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!
            > <http://docs.yahoo.com/info/terms/> Terms of Service.
            >
            >




            __________________________________
            Do you Yahoo!?
            Yahoo! Mail - now with 250MB free storage. Learn more.
            http://info.mail.yahoo.com/mail_250
          • Jiri Lundak
            William, Thanks for your input. ... The work load is highly assymetric indeed (by a factor of 12, to be precise). And shared components are the norm, because
            Message 5 of 29 , Jan 3, 2005
            • 0 Attachment
              William,

              Thanks for your input.

              <William.nichols@g...> wrote:
              > I agree that it's the preferred solution, but the limit of 10 people
              > becomes a problem if the work load is highly assymetric. If you have a
              > secondary workload for only one or two people, a separate team may be
              > counter productive. This is especially true if you have potential for
              > shared components because the product coupling requires more
              > inter-team communication.

              The work load is highly assymetric indeed (by a factor of 12, to be
              precise). And shared components are the norm, because it is actually
              it is actually one code base. Although management acted in the recent
              years as if it was developing individual solutions for each customer,
              it actually boils down to product development, if seen in the right
              perspective.

              I find this a fundamental difference in the mind set (project vs.
              product development).

              <William.nichols@g...> wrote:
              > The most important aspect of self-organization IMHO is that team
              > produced plans are more realistic while still aggressive.
              > In the case at hand, I would probably keep a single team, have the
              > team divide tasks into the appropriate backlog as you describe, and
              > sacrifice one or two people to the smaller project. That way, the
              > smaller project will have owners/advocates. If you need to sacrifice
              > 4, then you probably should fission into two teams. You might do
              > this, even for a small project, if it is time critical. Again, this
              > is a business decision. You need buy in from management.

              There actually comes in quite handy, that Scrum includes the quality
              to make deficiencies quickly/highly visibile. Problems in planning
              are made evident immediately.

              I like the idea of having one or two (or even more if available)
              people as kind of a SWAT team, holding away the distractions from the
              main team. James Coplien mentions a similar solution in his book
              "Organizational Patterns of Agile Software Development"
              (see 'Team per Task' and 'Sacrifice One Person').

              Jiri
            • Jiri Lundak
              Paul, ... 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
              Message 6 of 29 , 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/> .
              • Jiri Lundak
                Hi Ron, Thank you for the pointer. I read that metaphor some time back and never thought I would come into a situation, where I would find myself in a similar
                Message 7 of 29 , Jan 3, 2005
                • 0 Attachment
                  Hi Ron,

                  Thank you for the pointer.

                  I read that metaphor some time back and never thought I would come
                  into a situation, where I would find myself in a similar context.

                  You write about the 'King':
                  "The king is almost certainly not the development group, at least in
                  the XP context. In XP, business decisions are not made by development.
                  So from an XP viewpoint, the king is some kind of Big Customer. Kevin
                  Lawrence suggests that the king is the Customer Who Speaks With One
                  Voice. Brad Appleton mentions the idea of a Customer Advisory Board,
                  and suggests that the XP equivalent might be "One Customer Team". In a
                  product company, the role of king might be taken by a product
                  marketing committee, or the head of product marketing. In any case,
                  it's best if the king is a business-oriented decision maker."

                  What, if you have more than one king? Or, if you have one king and in
                  the background some shadow king, but both not talking with one voice?

                  It seams to me, that this is the time, where should be some fusion of
                  both positions, maybe some kind of forced 'royal pact'?

                  How can someone like a Scrum Master foster a unification, without
                  becoming the yard fool?

                  Jiri


                  --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                  <ronjeffries@X...> wrote:
                  > On Tuesday, December 28, 2004, at 12:15:12 PM, Royer, Paul 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.
                  >
                  > A related notion intended to force the conversation to start:
                  > http://www.xprogramming.com/xpmag/PetitionTheKing.htm .
                  >
                  > Ron Jeffries
                  > www.XProgramming.com
                  > If it is more than you need, it is waste. -- Andy Seidl
                • Jiri Lundak
                  Jeff, 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:
                  Message 8 of 29 , Jan 3, 2005
                  • 0 Attachment
                    Jeff,

                    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
                    products/releases?
                    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
                    releases?
                    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
                    divided?
                    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.

                    Cheers.
                    Jiri


                    --- 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.
                  • Jiri Lundak
                    Hi Clark, a) Unfortunately for us our company, as many do, has won a bid for this project on a fixed price contract basis. So we get a big sum of money,
                    Message 9 of 29 , Jan 3, 2005
                    • 0 Attachment
                      Hi Clark,

                      a) Unfortunately for us our company, as many do, has won a
                      bid for this project on a fixed price contract basis.
                      So we get a big sum of money, divided in monthly payments
                      over a period of two years, to finance the ongoing
                      development effort. At the end of the project all code
                      becomes the property of the customer. He has the right
                      to not give us any further work in the future, if not
                      satisfied.
                      Unfortunately the customer has no idea how to continue to
                      develop the system on his own or a third party, because
                      very much know-how in the business domain is needed, that
                      our partner, IBM, does not possess.
                      So even in the case that the project should be terminated
                      without being finished, there is the opinion in upper
                      management, that the investment is so big, that the
                      customer can not afford to invest once more the same sum
                      to complete the project.

                      b) Although this this would be a remote possibility (because
                      there are several other suppliers), this would not be
                      an easy switch, because there would have to be rewritten
                      many host programms that migrate data from the old host
                      environment to the one (the host programms being written
                      by our company's programmer over the period of the last
                      20 years). A bit you can call that kind of a supplier
                      lock in. Sure, with lots of money this could be possible.
                      But as a govermental firm (operating on tax money) they
                      try to save any single Swiss franc they can.

                      Hope this helps to give you a better picture.

                      Jiri


                      --- In scrumdevelopment@yahoogroups.com, "clarkeching" <lists@c...> wrote:
                      >
                      > Hi Jiri,
                      >
                      > I don't think we can properly help answer your question without
                      > knowing:
                      >
                      > a) How does your company *make money* from these
                      > projects/customers? Are they paid on completion of the work, as
                      > part of a joint-venture, or is this done a work and materials basis?
                      >
                      > b) What's the competive environment like for your company? For
                      > instance, can your customers easily move to another supplier?
                      >
                      > Since your employer is in business to make money your decision
                      > should be based on how you can help them to make the most money (now
                      > and in the future), not on minimising cost, technical
                      > considerations, efficiency, or on "fairly" balancing the needs of
                      > the many customers.
                      >
                      > BTW: you might want to look at the animations in this powerpoint
                      > presentaion, under "Tool 2 - Eliminate multitasking"
                      > http://www.clarkeching.com/files/clarke_ching_goldratt_toc_xpday_2004
                      > .ppt
                      > Clarke
                    • Jiri Lundak
                      Hi 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
                      Message 10 of 29 , Jan 3, 2005
                      • 0 Attachment
                        Hi 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?)

                        Jiri

                        --- In scrumdevelopment@yahoogroups.com, "Mike Beedle" <beedlem@e...>
                        wrote:
                        >
                        > I unfortunately haven't made time to write more about running Scrum for
                        > multiple projects, but here are some things we do:
                        >
                        > http://www.enterpriseagileprocess.com/practices.html
                        >
                        > - Mike
                        >
                        > -----Original Message-----
                        > From: jiri_lundak [mailto:jiri.lundak@l...]
                        > Sent: Monday, December 27, 2004 6: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 Links
                      • Ron Jeffries
                        ... I would do it by following the publication practices in the Petition the King article: I d publish what I was doing and make it clear that I wasn t doing
                        Message 11 of 29 , Jan 3, 2005
                        • 0 Attachment
                          On Monday, January 3, 2005, at 6:37:44 PM, Jiri Lundak wrote:

                          > What, if you have more than one king? Or, if you have one king and in
                          > the background some shadow king, but both not talking with one voice?

                          > It seams to me, that this is the time, where should be some fusion of
                          > both positions, maybe some kind of forced 'royal pact'?

                          > How can someone like a Scrum Master foster a unification, without
                          > becoming the yard fool?

                          I would do it by following the publication practices in the Petition
                          the King article: I'd publish what I was doing and make it clear
                          that I wasn't doing anything else.

                          I would also try to make decisions poorly enough to foster
                          unification among the requirements givers. One has to be careful not
                          to appear the fool, but it's amazing what a really bad proposed
                          decision or two will do when you've got someone in the room who
                          won't make up their mind.

                          I would also get them to at least make the budget clear: what
                          percentage of my effort should go to each king.

                          And of course, whenever you have too many kings, there's always
                          assassination. :)

                          Ron Jeffries
                          www.XProgramming.com
                          Think! -- Aretha Franklin
                        • mike.dwyer1@comcast.net
                          Ron is absolutely on the money. Traditional Program/Project Management approaches handle Ron s suggestion during the scoping and definition phase by having a
                          Message 12 of 29 , Jan 4, 2005
                          • 0 Attachment
                            Ron is absolutely on the money.  Traditional Program/Project Management approaches handle Ron's suggestion during the scoping and definition phase by having a section devoted to what is within scope and focus and more importantly what is not.  Of the two, stating what is NOT in scope is the more important.  Within the stuff I recommend you commit NOT to do is to work without approval of the business owner and to do only what they formally approve.  This, along with the infamous 'formal signoff' on the document smokes out the politicians.  It also causes much of the delays.  This is where traditional systems get in trouble as they do not make the business owner a task owner on the plan.  Therefore the slip is not attributed to the source.
                             
                            In the Agile environments I work in. we take this one step further and commit NOT to consume any resources that the business owner does not approve and to NOT deliver anything that has not been approved.
                             
                            We also carry the business owner as a milestone task owner and give a specified period of time for a response.  When it does not happen, that task - and its owner - need to answer for the slip.
                             
                            If it sounds like I am mixing Agile and traditional - rest assured that I am as I work in the land of the possible.
                             
                            --
                            Mike Dwyer

                            "I Keep six faithful serving-men
                            Who serve me well and true:
                            Their names are What and Where and When
                            And How and Why and Who." - Kipling
                             
                            -------------- Original message --------------

                            >
                            > On Monday, January 3, 2005, at 6:37:44 PM, Jiri Lundak wrote:
                            >
                            > > What, if you have more than one king? Or, if you have one king and in
                            > > the background some shadow king, but both not talking with one voice?
                            >
                            > > It seams to me, that this is the time, where should be some fusion of
                            > > both positions, maybe some kind of forced 'royal pact'?
                            >
                            > > How can someone like a Scrum Master foster a unification, without
                            > > becoming the yard fool?
                            >
                            > I would do it by following the publication practices in the Petition
                            > the King article: I'd publish what I was doing and make it clear
                            > that I wasn't doing anything else.
                            >
                            > I would also try to make decisions poorly enough to foster
                            > unification among the requirements givers. One has to be careful not
                            > to appear the fool, but it's amazing what a really bad proposed
                            > decision or two will do when you've got someone in the room who
                            > won't make up their mind.
                            >
                            > I would also get them to at least make the budget clear: what
                            > percentage of my effort should go to each king.
                            >
                            > And of course, whenever you have too many kings, there's always
                            > assassination. :)
                            >
                            > Ron Jeffries
                            > www.XProgramming.com
                            > Think! -- Aretha Franklin
                            >
                            >
                            >
                            >
                            > To Post a message, send it to: scrumdevelopment@...
                            > To Unsubscribe, send a blank message to:
                            > scrumdevelopment-unsubscribe@...
                            > 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
                            >
                            > <*> Your use of Yahoo! Groups is subject to:
                            > http://docs.yahoo.com/info/terms/
                            >
                            >
                            >
                            >
                          • mike.dwyer1@comcast.net
                            Ron Jeffries wrote Think! -- Aretha Franklin Does that mean she was an admirer of Thomas Watson? or was he a fan of hers? -- Mike Dwyer I Keep six
                            Message 13 of 29 , Jan 4, 2005
                            • 0 Attachment
                              Ron Jeffries wrote " Think! -- Aretha Franklin "
                              Does that mean she was an admirer of Thomas Watson? or was he a fan of hers?
                               
                              --
                              Mike Dwyer

                              "I Keep six faithful serving-men
                              Who serve me well and true:
                              Their names are What and Where and When
                              And How and Why and Who." - Kipling
                               
                              -------------- Original message --------------

                              >
                              > On Monday, January 3, 2005, at 6:37:44 PM, Jiri Lundak wrote:
                              >
                              > > What, if you have more than one king? Or, if you have one king and in
                              > > the background some shadow king, but both not talking with one voice?
                              >
                              > > It seams to me, that this is the time, where should be some fusion of
                              > > both positions, maybe some kind of forced 'royal pact'?
                              >
                              > > How can someone like a Scrum Master foster a unification, without
                              > > becoming the yard fool?
                              >
                              > I would do it by following the publication practices in the Petition
                              > the King article: I'd publish what I was doing and make it clear
                              > that I wasn't doing anything else.
                              >
                              > I would also try to make decisions poorly enough to foster
                              > unification among the requirements givers. One has to be careful not
                              > to appear the fool, but it's amazing what a really bad proposed
                              > decision or two will do when you've got someone in the room who
                              > won't make up their mind.
                              >
                              > I would also get them to at least make the budget clear: what
                              > percentage of my effort should go to each king.
                              >
                              > And of course, whenever you have too many kings, there's always
                              > assassination. :)
                              >
                              > Ron Jeffries
                              > www.XProgramming.com
                              > Think! -- Aretha Franklin
                              >
                              >
                              >
                              >
                              > To Post a message, send it to: scrumdevelopment@...
                              > To Unsubscribe, send a blank message to:
                              > scrumdevelopment-unsubscribe@...
                              > 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
                              >
                              > <*> Your use of Yahoo! Groups is subject to:
                              > http://docs.yahoo.com/info/terms/
                              >
                              >
                              >
                              >
                            • Clarke Ching
                              Hi Jiri, Thanks for your reply. ... bid for this project on a fixed price contract basis. So we get a big sum of money, divided in monthly payments over a
                              Message 14 of 29 , Jan 5, 2005
                              • 0 Attachment
                                Hi Jiri,
                                 
                                Thanks for your reply.
                                 
                                > a) Unfortunately for us our company, as many do, has won a
                                   bid for this project on a fixed price contract basis.
                                   So we get a big sum of money, divided in monthly payments
                                   over a period of two years, to finance the ongoing
                                   development effort. ... He has the right
                                   to not give us any further work in the future, if not
                                   satisfied.
                                 
                                That is kinda unfortunate!  So there is no immediate motivation for your company to deliver any earlier than promised.  In fact, by the sound of it, would you lose money if you did?
                                 
                                Clarke
                                 


                                From: Jiri Lundak [mailto:jiri.lundak@...]
                                Sent: 04 January 2005 00:31
                                To: scrumdevelopment@yahoogroups.com
                                Subject: [scrumdevelopment] Re: Multi-Project Development with Limited Resources


                                Hi Clark,

                                a) Unfortunately for us our company, as many do, has won a
                                   bid for this project on a fixed price contract basis.
                                   So we get a big sum of money, divided in monthly payments
                                   over a period of two years, to finance the ongoing
                                   development effort. At the end of the project all code
                                   becomes the property of the customer. He has the right
                                   to not give us any further work in the future, if not
                                   satisfied.
                                   Unfortunately the customer has no idea how to continue to
                                   develop the system on his own or a third party, because
                                   very much know-how in the business domain is needed, that
                                   our partner, IBM, does not possess.
                                   So even in the case that the project should be terminated
                                   without being finished, there is the opinion in upper
                                   management, that the investment is so big, that the
                                   customer can not afford to invest once more the same sum
                                   to complete the project.

                                b) Although this this would be a remote possibility (because
                                   there are several other suppliers), this would not be
                                   an easy switch, because there would have to be rewritten
                                   many host programms that migrate data from the old host
                                   environment to the one (the host programms being written
                                   by our company's programmer over the period of the last
                                   20 years). A bit you can call that kind of a supplier
                                   lock in. Sure, with lots of money this could be possible.
                                   But as a govermental firm (operating on tax money) they
                                   try to save any single Swiss franc they can.

                                Hope this helps to give you a better picture.

                                Jiri


                                --- In scrumdevelopment@yahoogroups.com, "clarkeching" <lists@c...> wrote:
                                >
                                > Hi Jiri,
                                >
                                > I don't think we can properly help answer your question without
                                > knowing:
                                >
                                > a) How does your company *make money* from these
                                > projects/customers?  Are they paid on completion of the work, as
                                > part of a joint-venture, or is this done a work and materials basis?
                                >
                                > b) What's the competive environment like for your company?  For
                                > instance, can your customers easily move to another supplier?
                                >
                                > Since your employer is in business to make money your decision
                                > should be based on how you can help them to make the most money (now
                                > and in the future), not on minimising cost, technical
                                > considerations, efficiency, or on "fairly" balancing the needs of
                                > the many customers. 
                                >
                                > BTW: you might want to look at the animations in this powerpoint
                                > presentaion, under "Tool 2 - Eliminate multitasking"
                                > http://www.clarkeching.com/files/clarke_ching_goldratt_toc_xpday_2004
                                > .ppt
                                > Clarke





                                To Post a message, send it to:   scrumdevelopment@...
                                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



                              • Ron Jeffries
                                ... Unless getting parts sooner than promised might make him more satisfied ... ... Unless it s really underbid, in which case you d lose less by getting done
                                Message 15 of 29 , Jan 5, 2005
                                • 0 Attachment
                                  On Wednesday, January 5, 2005, at 2:03:04 PM, Clarke Ching wrote:

                                  >> a) Unfortunately for us our company, as many do, has won a
                                  > bid for this project on a fixed price contract basis.
                                  > So we get a big sum of money, divided in monthly payments
                                  > over a period of two years, to finance the ongoing
                                  > development effort. ... He has the right
                                  > to not give us any further work in the future, if not
                                  > satisfied.

                                  > That is kinda unfortunate! So there is no immediate motivation for your
                                  > company to deliver any earlier than promised.

                                  Unless getting parts sooner than promised might make him more
                                  satisfied ...

                                  > In fact, by the sound of it,
                                  > would you lose money if you did?

                                  Unless it's really underbid, in which case you'd lose less by
                                  getting done sooner, lose fewer people by working less overtime, or
                                  get more money by making him happy ...

                                  Ron Jeffries
                                  www.XProgramming.com
                                  I could be wrong, but I'm not. --Eagles, Victim of Love
                                • Angelo Schneider
                                  Hi, a bit late but better late than never :D In the german magazine OBJEKTspectrum was an article about product family development with interlocked SCRUMs
                                  Message 16 of 29 , Jan 6, 2005
                                  • 0 Attachment
                                    Hi,

                                    a bit late but better late than never :D

                                    In the german magazine "OBJEKTspectrum" was an article about "product
                                    family" development with interlocked SCRUMs (product family backlog
                                    interlocked with several product backlogs).

                                    I don't remember the issue, but it was a 2004 issue. The web page is:
                                    www.sigs.de

                                    The article was quite good and as you are from switzerland I suggest to
                                    get a copy.

                                    Regards,
                                    Angelo

                                    --------------------------- www.oomentor.de --------------------------
                                    Angelo Schneider OOAD/UML Angelo.Schneider@...
                                    Putlitzstr. 24 Patterns/FrameWorks Fon: +49 721 9812465
                                    76137 Karlsruhe C++/JAVA Fax: +49 721 9812467
                                  • Mike Beedle
                                    (Jiri Hi 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
                                    Message 17 of 29 , Jan 6, 2005
                                    • 0 Attachment

                                       

                                      (Jiri
                                      "

                                      Hi 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?

                                       

                                      "

                                            )

                                       

                                      Jiri:

                                       

                                      The "Shared Resources Scrum Master" is the Scrum Master for the

                                      Shared Resources team, if there is one (either the team or the

                                      ScrumMaster for it).  (Don't you love that answer?? :-)

                                       

                                      Let me explain.  The "shared resources team members" have as a goal:

                                       

                                            * promote the conceptual integrity of the enterprise architecture

                                        and applications

                                            * promote and facilitate enterprise component reuse

                                            * provide coaching, training and mentoring for application development      

                                        team members (both process and technology)

                                       

                                      The "Shared Resources" team codes stuff in cooperation with other teams.  

                                      The "Shared Resources" team members are in many cases on loan to other teams.  

                                      These members carry "central DNA", that reminds the application teams there are:

                                       

                                      ·        design and architectural standards 

                                       

                                      This prevents application developers from re-architecting applications

                                      that are not compatible with enterprise standards.

                                       

                                      ·        reusable business components (some under development)

                                       

                                            This prevents business developers from re-inventing the
                                            "business component wheel"

                                      ·        coding standards

                                       

                                            This helps and reminds the application developers that there are

                                      enterprise coding standards  (The goal is that all code throughout

                                      the enterprise in a particular architecture looks and feels the same.)

                                           

                                      ·        infrastructure components that need to be used

                                       

                                            This prevents teams from recreating things like "single sign on",

                                            "authorization services", workflow, document management, faxing,

                                      printing, logging, etc., etc.

                                       

                                       

                                      The "Shared Resources team members" live with the teams, but meet with the

                                      "Shared Resources Scrum Master" at least once again in the same room, where

                                      the 3 questions are asked.  (Yes, those 3 questions you already know from

                                      basic Scrum.)

                                       

                                      The goal of the Shared Resources team is to eventually have teams with no

                                      "Shared Resource team members", and instead have a representative of

                                      the application come to the "Shared Resources Meetings".

                                       

                                      The "shared resources team" is sometimes called "Architecture team", but

                                      I prefer "Shared resources" because the Architecture name has in some

                                      places negative connotations, as in "high-level non-writing code experts

                                      on top of white pedestals", etc.  Actually, I believe there is a

                                      "good breed" of architects that resemble more "coaches", but then we

                                      had to call the team the "Coaching Team", which is even harder to understand.

                                       

                                      (Jiri

                                      "2. What do you mean by 'Production Super Sprints'?"

                                            )

                                       

                                      Many applications are developed concurrently, most of which use and

                                      deploy reusable components.  Because of these dependencies, the

                                      "reusable code base" needs to be tested and deployed all-at-once in a

                                      "Production Super Sprint", which encompass one or more individual

                                      application Sprints.

                                       

                                      "Production Super Sprints" are self-similar at a higher level of scale

                                      to Sprints.  (As "Scrum of Scrums" for multiple teams are self-similar

                                      to "Scrums".)

                                       

                                      In our case we do scaling at two levels: technical and management.

                                       

                                      So our "Scrum of Scrums" apply to:

                                       

                                            * application team leaders (to decide Production Super Sprints and

                                        Enterprise Releases)

                                            * technical leaders (to decide Production Super Sprint contents)

                                            * Shared Resources team members (to evolve Enterprise Development and

                                              Architecture through application Sprints and Production Super Sprints)

                                            * Shared Resources sub-teams (to coordinate dependencies among shared

                                              Components within the Shared Resources team.)

                                       

                                      Of course then you have regular Scrums:

                                       

                                            * Application Scrums

                                            * Shared Resources Scrums

                                       

                                      (Jiri

                                      "3. Would be intersting to hear, how you do this in the concrete

                                         -> Integration Testing across applications and reusable components?

                                      "

                                            )

                                       

                                      Throw all enterprise applications into a single integration server and

                                      bang away (through both automated tests and manual tests).

                                       


                                      (Jiri

                                            (Btw: What happend to XBreed?))

                                       

                                      XBreed was renamed "Enterprise Agile Process" to avoid confusion -- a

                                      much better name for its purpose:

                                       

                                            Concurrent Agile Application Development

                                       

                                      (All references to XP engineering practices have been removed, since that

                                      was most of the confusing element.  "Enterprise Agile Process" can

                                      use *any* engineering practices.)

                                       

                                      Using this system we developed 17 applications at a large PBM here in Chicago ,

                                      and since they have extended this number to something like 25 apps.

                                       

                                      To my knowledge, this is the highest number of concurrent applications

                                      being developed in an "agile way" using reusable components.  (Some of

                                      the apps, at least 5, are very large 200+ screens.)

                                       

                                      This method has been refined over the years.  Our first experience

                                      with it was in 1996 at a large benefits management company, and then

                                      used it again in Insurance, and Financials, with different levels of

                                      success.

                                       

                                      The challenge for Agility and Scrum in particular today is:

                                       

                                            Enterprise Agile Development

                                       

                                      with multiple concurrent and dependent projects being developed all-at-once.

                                       

                                      This is where Agility will make "most business sense" i.e. highest

                                      ROI and risk mitigation.

                                       

                                      At this level of scale Agile Software Development is almost synonymous with

                                      Agile Business Development, and for the most part:

                                       

                                      the enterprise software is the business

                                       

                                      (Think Telecom, Financials, Insurance, etc.)

                                       

                                      - Mike

                                       

                                      Michael A. Beedle

                                      CEO

                                      New Governance Inc.

                                      2275 Half Day Rd,Suite 350

                                      Bannockburn, IL 60015

                                      Email: mike.beedle@...

                                      www: http://www.newgovernance.com

                                      Office: 847-821-2631

                                      Cell: 847-840-9890

                                       

                                    Your message has been successfully submitted and would be delivered to recipients shortly.