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

Re: [scrumdevelopment] Re: Multi-Project Development with Limited Resources

Expand Messages
  • 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 1 of 29 , Jan 3, 2005
      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 2 of 29 , Jan 4, 2005
        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 3 of 29 , Jan 4, 2005
          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 4 of 29 , Jan 5, 2005
            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 5 of 29 , Jan 5, 2005
              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 6 of 29 , Jan 6, 2005
                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 7 of 29 , Jan 6, 2005

                   

                  (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.