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

Re: Multi-Project Development with Limited Resources

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.