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

Re: Multi-Project Development with Limited Resources

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