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

Re: [scrumdevelopment] Shocking the PMI Crowd a Bit

Expand Messages
  • Fabian Longhitano
    Bud, Can you give more details about your method for estimate? Thanks, Fabián ... Bud, Can you give more details about your method for estimate? Thanks,
    Message 1 of 23 , Oct 2, 2006
      Bud,
      Can you give more details about your method for estimate?
      Thanks,
      Fabián

      On 10/2/06, Bud Cookson < Bud.Cookson@...> wrote:

      Scott - a good article on why software development is different than construction of a building.  However, it seems like a gross exaggeration to say that the BRUF approach to software is a bad thing.  What I would say is that you can only specify the requirements to the level of detail that is available from the stakeholders including their ability to conceive what is truly "needed".  At the same time, this compromise must be traded against the cost of reorganization and trial.  As in all things, there is no absolute, right and appropriate answer.
       
      As far as estimates being inaccurate at the beginning of a project, they are only as inaccurate as the requirements.  I agree that we learn things during the course of the project which will help us do things better or differently than were conceived at the beginning of the project but this doesn't mean that the estimates are inaccurate.  In fact, with a method that I have developed, I can give you a pretty good estimate of how big the "unknowns" are in the project which you can then use as the basis for your project budgets or "ranges" as you have appropriately pointed out.  I know this system works because ~90% of my software projects have come in On-Time and On-Budget so there must be something to it.
       
      Agile software development is a great thing and has huge advantages in many cases.  However, not all cases fit the model that is supported by the agile approaches.  Again, it comes down to the compromises which are based on lots of factors.
       
      Keep up the good work and great point of discussion.  Unfortunately, not all PMPs have experience in the software world, especially those environments and projects where agile makes sense although this publication and article are directed at the IT types so they should.  Hope everyone understands what is being said.
       
      BUD


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroup s.com] On Behalf Of Scott W. Ambler
      Sent: Monday, October 02, 2006 10:48 AM
      To: agilearticles@yahoogroups.com; ambysoft@yahoogroups.com; scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Shocking the PMI Crowd a Bit

      In the current issue of the PMI's ISSIG (Information Systems Specific
      Interest Group) Review at
      http://www.pmi-issig.org/kb/ISSIG%20Review/ISSIG_Review_06_2H.pdf I have an
      article questioning the wisdom of writing requirements specifications early
      in the lifecycle of a project. An important aspect of the article is that
      it argues that if a detailed requirements spec early in the lifecycle is a
      bad idea, then any practice based on this approach is also suspect.

      If you happen to work with traditional project managers, or at least know
      some, you might want to pass that URL on to them. Hopefully it will give
      them something to think about. ;-)

      - Scott
      Scott W. Ambler
      Practice Leader Agile Development, IBM
      http://www-306.ibm.com/software/rational/bios/ambler.html

      Every organization gets the process that it deserves.


    • PaulOldfield1@aol.com
      (responding to Bud) ... There will be an appropriate answer in a specific situation, but that s not what I want to talk about. There s an additional overhead
      Message 2 of 23 , Oct 3, 2006
        (responding to Bud)
         
        > .. it seems like a gross exaggeration to say that the BRUF
        > approach to software is a bad thing.  What I would say is
        > that you can only specify the requirements to the level of
        > detail that is available from the stakeholders including their
        > ability to conceive what is truly "needed".  At the same time,
        > this compromise must be traded against the cost of
        > reorganization and trial.  As in all things, there is no absolute,
        > right and appropriate answer.
         
        There will be an appropriate answer in a specific situation, but
        that's not what I want to talk about.
         
        There's an additional overhead to doing BRUF; you would need
        either to expend more effort to record the detail up front, or to
        expend duplicated effort re-doing this work when the information
        is about to be used... normally.  There may be ways of recording
        the requirements (say as acceptance tests) that avoid this
        extra overhead, but I think this degree of formality up-front
        would not be a good thing in general.  Agreed, you need to trade
        off the benefits against the costs.
         
        >  In fact, with a method that I have developed, I can give you a
        > pretty good estimate of how big the "unknowns" are in the
        > project which you can then use as the basis for your project
        > budgets or "ranges" as you have appropriately pointed out.
        >  I know this system works because ~90% of my software
        > projects have come in On-Time and On-Budget so there must
        > be something to it.
         
        This capacity to estimate becomes progressively easier when
        you work: in the same domain; with the same company; with
        the same team; on the same type of applications.  In case you
        manage good (~90% OT, OB) predictions toward the left end of
        the list, I'd be interested in an outline of your approach.  (I'm
        assuming you're making these predictions c. 10-20% into
        the project; earlier would be impressive, later would not).
         
        Paul Oldfield
         
         
      • Bud Cookson
        Fabian - I would be glad to give you some insights into this approach. Let me start by saying that this approach is an estimate . Is it useful? Absolutely!
        Message 3 of 23 , Oct 3, 2006
          Fabian - I would be glad to give you some insights into this approach.  Let me start by saying that this approach is an "estimate".  Is it useful?  Absolutely!  Is it always precise?  No!  Is it better than nothing?  Yes.
           
          I also do not propose that this be used in the agile world as a regular approach.  I say this because I am sure that I will be flamed for proposing something that is not necessary in the agile development methodologies and rightly so.  When you have the ability to adjust the scope while maintaining a constant expenditure rate and timeboxing the schedule, then this methodology is not needed.  However, if your customer/sponsor/client can define the requirements and wants a solid plan, then this approach is really necessary.
           
          The methodology is based on four steps.  It is what I call a "Category 3 Estimate" or an "Estimate Of The Estimate Accuracy" or an "Estimate Of The Unknowns".  What we are attempting to do is to estimate how much we know about the project and translating this into an estimate of the size of the unknowns in the project.  Here are the steps.
           
          1.  You brainstorm the factors that could influence the accuracy of your Category 1 estimates (those things that you know you know, i.e., the requirements).  These are such things as the experience of the estimator, the newness of the technology, the maturity of the customer, etc.  This list can be as long or as short as you want.  I have a list of about 25 items that I normally use but this can be adjusted based on your experiences.
           
          2.  You categorize each of these factors into whether it has a low, medium or high impact on the accuracy of the estimate.  I typically only use the three categories but you can use more if you want.
           
          3.  The artistic portion of this method is to "guess" at what the potential impact level is for each of the categories.  Yes, this is a guess but it utilizes our best idea of what the potential impact might be.  In many cases, this might be 10/20/40%.  In other cases, it might be 10/50/400%.  The actual numbers are important as a measure of the level of potential impact and you need to be open to what the potential values might be.  They will not be 10/20/30% in every case.  Just remember the statistics that say that the average overrun on a software project is something like 100%.  Therefore, it is easy to say that it is not atypical to have values here of 200 or even 500%.  The values are left to your best judgement.
           
          4.  The final step is to calculate a weighted average of the percentages selected in step 3 based on the number of the factors from step 1 that are in each category.  You will come out with a percentage of inaccuracy that is due to each of the categories which are then added together to produce a single number.  This is the Category 3 estimate which is a measure of how large the unknowns are for this project.
           
          The results of this technique can be used in several different ways.  The first is that the final, single number can be multiplied times the Category 1 estimates to produce a final estimate.  Another approach is to apply the Low category number as a Contingency to the project and take the Medium and High numbers and apply these to the Category 1 estimates.  You can keep the entire Category 3 estimate as a contingency and dole it out as the unknowns are quantified.  The specific approach here is dependent on lots of factors.  However, without doing this, you are only estimating a part of the project and therefore setting yourself up for failure.
           
          Again, this is not necessary in a true agile project because the unknowns are what the methodology is all about and they are accounted for in the velocity and the use of the velocity in predicting rates of progress.  However, in those cases where it is necessary to plan the project to completion, this is a very, very important tool.
           
          Hope that helps.  I actually have a spreadsheet that I use for this calculation which I am more than happy to provide to anyone who would like a copy.  Just send me an email directly.
           
          Best regards,   BUD


          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Fabian Longhitano
          Sent: Monday, October 02, 2006 8:16 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Shocking the PMI Crowd a Bit

          Bud,
          Can you give more details about your method for estimate?
          Thanks,
          Fabián

          On 10/2/06, Bud Cookson < Bud.Cookson@ usa.net> wrote:

          Scott - a good article on why software development is different than construction of a building.  However, it seems like a gross exaggeration to say that the BRUF approach to software is a bad thing.  What I would say is that you can only specify the requirements to the level of detail that is available from the stakeholders including their ability to conceive what is truly "needed".  At the same time, this compromise must be traded against the cost of reorganization and trial.  As in all things, there is no absolute, right and appropriate answer.
           
          As far as estimates being inaccurate at the beginning of a project, they are only as inaccurate as the requirements.  I agree that we learn things during the course of the project which will help us do things better or differently than were conceived at the beginning of the project but this doesn't mean that the estimates are inaccurate.  In fact, with a method that I have developed, I can give you a pretty good estimate of how big the "unknowns" are in the project which you can then use as the basis for your project budgets or "ranges" as you have appropriately pointed out.  I know this system works because ~90% of my software projects have come in On-Time and On-Budget so there must be something to it.
           
          Agile software development is a great thing and has huge advantages in many cases.  However, not all cases fit the model that is supported by the agile approaches.  Again, it comes down to the compromises which are based on lots of factors.
           
          Keep up the good work and great point of discussion.  Unfortunately, not all PMPs have experience in the software world, especially those environments and projects where agile makes sense although this publication and article are directed at the IT types so they should.  Hope everyone understands what is being said.
           
          BUD


          From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelopment@yahoogroup s.com] On Behalf Of Scott W. Ambler
          Sent: Monday, October 02, 2006 10:48 AM
          To: agilearticles@ yahoogroups. com; ambysoft@yahoogroups.com; scrumdevelopment@ yahoogroups. com
          Subject: [scrumdevelopment] Shocking the PMI Crowd a Bit

          In the current issue of the PMI's ISSIG (Information Systems Specific
          Interest Group) Review at
          http://www.pmi- issig.org/ kb/ISSIG% 20Review/ ISSIG_Review_ 06_2H.pdf I have an
          article questioning the wisdom of writing requirements specifications early
          in the lifecycle of a project. An important aspect of the article is that
          it argues that if a detailed requirements spec early in the lifecycle is a
          bad idea, then any practice based on this approach is also suspect.

          If you happen to work with traditional project managers, or at least know
          some, you might want to pass that URL on to them. Hopefully it will give
          them something to think about. ;-)

          - Scott
          Scott W. Ambler
          Practice Leader Agile Development, IBM
          http://www-306. ibm.com/software /rational/ bios/ambler. html

          Every organization gets the process that it deserves.


        • Bud Cookson
          Paul - some comments on your thoughts. Thanks. BUD PaulOldfield1@aol.com said on Tuesday, October 03, 2006 1:48 AM ... I
          Message 4 of 23 , Oct 3, 2006
            Paul - some comments on your thoughts.  Thanks.   BUD
             
            PaulOldfield1@...  said on Tuesday, October 03, 2006 1:48 AM >> 

             >> There's an additional overhead to doing BRUF; you would need
             >> either to expend more effort to record the detail up front, or to
             >> expend duplicated effort re-doing this work when the information
             >> is about to be used... normally.  There may be ways of recording
             >> the requirements (say as acceptance tests) that avoid this
             >> extra overhead,  ...
             
            I agree that there is a cost involved in doing this documentation, the question becomes whether it has value.  In my experience it does.  The question becomes HOW MUCH detail to do at the front end.  It doesn't involve specifying everything.  It is a matter of defining ENOUGH that we can all agree that we are headed in the right direction.  Even though acceptance tests are a critical part of managing a project because they define the completion criteria, I find that non-technical users / customers aren't able to think in these terms at the beginning.  However, once the requirements are elicited, they can then turn them around into acceptance criteria.
             
             >> This capacity to estimate becomes progressively easier when
             >> you work: in the same domain; with the same company; with
             >> the same team; on the same type of applications.  In case you
             >> manage good (~90% OT, OB) predictions toward the left end of
             >> the list, I'd be interested in an outline of your approach.  (I'm
             >> assuming you're making these predictions c. 10-20% into
             >> the project; earlier would be impressive, later would not). 
             
            I wish that I was able to say that I have worked in the same domain for every project.  Unfortunately, this hasn't been the case.  I have worked in embedded systems, manufacturing control systems, financial / accounting systems, online web applications, network management systems and miscellaneous desktop applications.  As far as when these estimates are done, they are typically done at the 5 to 20% area of a project.  I don't count those situations like my first project job where we kept changing the estimates and completion date until the last day so we always completed on-time and on-budget.  The 90% figure is based on projects that were estimated in the early phases of the project and were managed to completion.  Yes, there were changes along the way but there isn't a project that doesn't.  However, with good Project Management, these changes are taken in stride and when the customer expectations are managed correctly, the results are spectacular.  it doesn't work perfectly but no project does.  This estimating technique (described in another email) just gives you a better chance of being successful because you are accounting for all of the project potentials to the best of your ability. 
             
            .

          • Scott Ambler
            Responding to several at once, sorry for any confusion. - Scott ... Yes, the references that I provide actually include a lot of other references. The article
            Message 5 of 23 , Oct 3, 2006
              Responding to several at once, sorry for any confusion.

              - Scott
              --- In scrumdevelopment@yahoogroups.com, "qcsmichael1" <mschmidt@...>
              wrote:
              > P.S. You might consider adding authors other than yourself to the
              > suggested reading list. There's a lot of good sutff out there. : )

              Yes, the references that I provide actually include a lot of other
              references. The article in the PMI article summarizes many of my
              previous writings. Those are known quantities, so I reference those.

              --- In scrumdevelopment@yahoogroups.com, "mnbluesguy" <tannen@...>
              wrote:

              > I think my only critique of the article are your statements about
              > Earned Value. Earned Value can be used to measure the 'value' of
              > completed/done work. It is all a matter of how you define done. In
              > Agile we define done as working software. When using Earned Value,I
              > insisted we develop schedules based on working functionality rather
              > than software lifecycles. Software lifecycles are only about the
              > process for developing software; not measuring the "doneness" of the
              > application.
              >

              Yes, that's an incredibly good idea which I promote whole heartedly.
              Unfortunately, many people based "earned value" on delivery of
              documents, not delivery of functionality. The comments were directed
              at them.



              --- In scrumdevelopment@yahoogroups.com, "Bud Cookson"
              <Bud.Cookson@...> wrote:
              >
              > Scott - a good article on why software development is different than
              > construction of a building. However, it seems like a gross
              exaggeration to
              > say that the BRUF approach to software is a bad thing.

              Perhaps. But, the numbers seem to show otherwise. The Chaos Report
              shows that project teams taking a BRUF approach on average deliver
              45% functionality that is never used by their end users, when they
              deliver at all. That's not so good, IMHO. See
              http://www.agilemodeling.com/essays/examiningBRUF.htm for details.

              >What I would say is
              > that you can only specify the requirements to the level of detail
              that is
              > available from the stakeholders including their ability to conceive
              what is
              > truly "needed".

              Sounds pretty risky to me, and the numbers seem to show that it is.
              Maybe you can make this approach work, but on average most
              organizations seem to be pretty bad at it.

              > At the same time, this compromise must be traded against
              > the cost of reorganization and trial. As in all things, there is no
              > absolute, right and appropriate answer.

              Exactly, you need to choose the right approach for the situation.
              Unfortunately, my experience is that many people have never even
              considered the concept that the BRUF approach might not be the
              greatest idea in the world, or that they have choices available to
              them that seem to work better in practice. Hence the article.

              - Scott
            • Bud Cookson
              ... . I would agree heartily.
              Message 6 of 23 , Oct 3, 2006
                 On Tuesday, October 03, 2006 4:10 PM , Scott Ambler said:

                 >> Exactly, you need to choose the right approach for the situation. 
                 >> Unfortunately, my experience is that many people have never even 
                 >> considered the concept that the BRUF approach might not be the 
                 >> greatest idea in the world, or that they have choices available to 
                 >> them that seem to work better in practice. Hence the article.

                .
                  I would agree heartily.  The biggest problem that I see in the Project Management world is that there are too many people who know how to do a Gantt chart in MSProject but have no comprehension of the basic concepts of Project Management.  It is not an art that can be done by rote.  It has at very high percentage of soft skills along with the whole issue of soft requirements in the software arena.  It is my hope, as well, that your article will provide some perspective for others. 
                 
                Keep on writing.   BUD 
              • Timothy H. Lund
                I think PMIers have plenty of understanding of how to run a traditional, non-software project. Believe it or not, all those Gantt charts, work breakdown
                Message 7 of 23 , Oct 4, 2006
                  I think PMIers have plenty of understanding of how to run a traditional, non-software project. Believe it or not, all those Gantt charts, work breakdown structures, and critical paths make sense when you're constructing a building or manufacturing something. It's just that when you try to apply them to software (such as we did with the waterfall method oh-so-many years ago), they break down because of the ambiguous nature of software.
                   
                  ~Tim
                   


                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Bud Cookson
                  Sent: Tuesday, October 03, 2006 6:25 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: RE: [scrumdevelopment] Re: Shocking the PMI Crowd a Bit

                   On Tuesday, October 03, 2006 4:10 PM , Scott Ambler said:

                   >> Exactly, you need to choose the right approach for the situation. 
                   >> Unfortunately, my experience is that many people have never even 
                   >> considered the concept that the BRUF approach might not be the 
                   >> greatest idea in the world, or that they have choices available to 
                   >> them that seem to work better in practice. Hence the article.

                  .
                    I would agree heartily.  The biggest problem that I see in the Project Management world is that there are too many people who know how to do a Gantt chart in MSProject but have no comprehension of the basic concepts of Project Management.  It is not an art that can be done by rote.  It has at very high percentage of soft skills along with the whole issue of soft requirements in the software arena.  It is my hope, as well, that your article will provide some perspective for others. 
                   
                  Keep on writing.   BUD 

                • Keith Sader
                  Yes, those charts, wbds, and crit paths make sense during the *construction* phase of a project. Since most(all?) of sofware development is design, these
                  Message 8 of 23 , Oct 4, 2006
                    Yes, those charts, wbds, and crit paths make sense during the *construction* phase of a project.  Since most(all?) of sofware development is design, these artifacts don't fit.

                    Here's a question: how do we get PMI, and other management schools to understand that software construction is performed by the compiler/interpreter?

                    On 10/4/06, Timothy H. Lund <thl@...> wrote:

                    I think PMIers have plenty of understanding of how to run a traditional, non-software project. Believe it or not, all those Gantt charts, work breakdown structures, and critical paths make sense when you're constructing a building or manufacturing something. It's just that when you try to apply them to software (such as we did with the waterfall method oh-so-many years ago), they break down because of the ambiguous nature of software.
                     
                    ~Tim
                     




                    --
                    Keith Sader
                    ksader@...
                    http://www.sader-family.org/roller/page/ksader
                    (coming back)http://www.saderfamily.org/roller/page/ksader
                  • Timothy H. Lund
                    To me, the first step is to get them to acknowledge that software projects are different than other projects for exactly that reason. Once you can establish
                    Message 9 of 23 , Oct 4, 2006
                      To me, the first step is to get them to acknowledge that software projects are different than other projects for exactly that reason. Once you can establish that, it forces them to make a distinction and study the differences (which is the kind of thing they'll probably be interested in).
                       
                      Specifically, I would think the differences you'd want to highlight are:
                      - Software requirements are vague, change quickly, and shift in priority as value is delivered.
                      -Software construction is relatively cheap.
                      -Software changes are relatively easy to make.
                       
                      These paradigm shifts from traditional project management blow the traditional project management model out of the water -- an approach which minimizes the risk of needing changes and expensive construction by increasing planning based on stable requirements and the ability to do a concrete design (no pun intended).
                       
                      I would think if you get that point across to the PMI, you'll get their attention.
                       
                      Also note that the basic project goals for a software project DO line up with other projects: the project should be done on time, within budget, and the customer should be happy; so we have something in common with PMIers (whether you like to admit it or not ;-).
                       
                      ~Tim
                       


                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Keith Sader
                      Sent: Wednesday, October 04, 2006 9:59 AM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: Re: [scrumdevelopment] Re: Shocking the PMI Crowd a Bit

                      Yes, those charts, wbds, and crit paths make sense during the *construction* phase of a project.  Since most(all?) of sofware development is design, these artifacts don't fit.

                      Here's a question: how do we get PMI, and other management schools to understand that software construction is performed by the compiler/interprete r?

                      On 10/4/06, Timothy H. Lund <thl@quantumleap. us> wrote:

                      I think PMIers have plenty of understanding of how to run a traditional, non-software project. Believe it or not, all those Gantt charts, work breakdown structures, and critical paths make sense when you're constructing a building or manufacturing something. It's just that when you try to apply them to software (such as we did with the waterfall method oh-so-many years ago), they break down because of the ambiguous nature of software.
                       
                      ~Tim
                       




                      --
                      Keith Sader
                      ksader@gmail. com
                      http://www.sader- family.org/ roller/page/ ksader
                      (coming back)http:// www.saderfamily. org/roller/ page/ksader

                    • Peter Hundermark
                      ... *construction* ... Give them the article The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka (Published in Harvard Business
                      Message 10 of 23 , Oct 5, 2006
                        --- In scrumdevelopment@yahoogroups.com, "Keith Sader" <ksader@...> wrote:
                        >
                        > Yes, those charts, wbds, and crit paths make sense during the
                        *construction*
                        > phase of a project. Since most(all?) of sofware development is design,
                        > these artifacts don't fit.
                        >
                        > Here's a question: how do we get PMI, and other management schools to
                        > understand that software construction is performed by the
                        > compiler/interpreter?
                        >

                        Give them the article "The New New Product Development Game" by
                        Hirotaka Takeuchi and Ikujiro Nonaka (Published in Harvard Business
                        Review, January 1986) to read?
                      • Graeme Matthew
                        Scott, I so agree with your article. Im doing a contract at the moment and there is so much documentation that it is actually useless. The functional
                        Message 11 of 23 , Oct 5, 2006
                          Scott, I so agree with your article.

                          Im doing a contract at the moment and there is so much documentation
                          that it is actually useless. The functional specification is 324 pages
                          !!!!! on my first day I asked one question and guess what the func spec
                          did not handle it and that was for one feature, oops looks like another
                          change request !

                          One of the strange things I have noticed is that with a massive project
                          governance and BDUF that companies dont actually look at the cost of all
                          involved parties to get to a point where they or a vendor can actually
                          start coding. The company where I am at now produced a Proof of Concept
                          in 8 weeks without any specification, simply time and materials with
                          direct collaboration with a vendor. This POC is now in production in 50
                          sites ! Minimal Documentation !

                          Now they say ok we need to do it nationally so lets put it into our
                          project management framework. Here we go, ultimate perfection of waste !
                          I say refactor the POC and make it work! Well the functional spec was
                          finished in February this year, we are now in October and they are doing
                          a 2 month data model and requirements finalisation exercise. Then dev
                          starts i.e. January 2007. Budget / On Time ? what about value !!!!!

                          Now what really makes me go oh is that it actually is not that much of a
                          complex application. The POC works !

                          Then I fainted and had to go for a triple by pass when the leaders say
                          we need strong governance and control ! well lets spend $500,000 getting
                          to the dev phase (i.e we start delivering working software) then the
                          vendor quotes $1.1 million to develop, so its now 1.6 why not just have
                          time and materials could have got it for 600,000 ! And then I hear we
                          are using FDD for the design and build ! so I have 324 pages as my
                          features list :-) sure !

                          Regards

                          Graeme

                          Scott Ambler wrote:
                          > Responding to several at once, sorry for any confusion.
                          >
                          > - Scott
                          > --- In scrumdevelopment@yahoogroups.com, "qcsmichael1" <mschmidt@...>
                          > wrote:
                          >
                          >> P.S. You might consider adding authors other than yourself to the
                          >> suggested reading list. There's a lot of good sutff out there. : )
                          >>
                          >
                          > Yes, the references that I provide actually include a lot of other
                          > references. The article in the PMI article summarizes many of my
                          > previous writings. Those are known quantities, so I reference those.
                          >
                          > --- In scrumdevelopment@yahoogroups.com, "mnbluesguy" <tannen@...>
                          > wrote:
                          >
                          >
                          >> I think my only critique of the article are your statements about
                          >> Earned Value. Earned Value can be used to measure the 'value' of
                          >> completed/done work. It is all a matter of how you define done. In
                          >> Agile we define done as working software. When using Earned Value,I
                          >> insisted we develop schedules based on working functionality rather
                          >> than software lifecycles. Software lifecycles are only about the
                          >> process for developing software; not measuring the "doneness" of the
                          >> application.
                          >>
                          >>
                          >
                          > Yes, that's an incredibly good idea which I promote whole heartedly.
                          > Unfortunately, many people based "earned value" on delivery of
                          > documents, not delivery of functionality. The comments were directed
                          > at them.
                          >
                          >
                          >
                          > --- In scrumdevelopment@yahoogroups.com, "Bud Cookson"
                          > <Bud.Cookson@...> wrote:
                          >
                          >> Scott - a good article on why software development is different than
                          >> construction of a building. However, it seems like a gross
                          >>
                          > exaggeration to
                          >
                          >> say that the BRUF approach to software is a bad thing.
                          >>
                          >
                          > Perhaps. But, the numbers seem to show otherwise. The Chaos Report
                          > shows that project teams taking a BRUF approach on average deliver
                          > 45% functionality that is never used by their end users, when they
                          > deliver at all. That's not so good, IMHO. See
                          > http://www.agilemodeling.com/essays/examiningBRUF.htm for details.
                          >
                          >
                          >> What I would say is
                          >> that you can only specify the requirements to the level of detail
                          >>
                          > that is
                          >
                          >> available from the stakeholders including their ability to conceive
                          >>
                          > what is
                          >
                          >> truly "needed".
                          >>
                          >
                          > Sounds pretty risky to me, and the numbers seem to show that it is.
                          > Maybe you can make this approach work, but on average most
                          > organizations seem to be pretty bad at it.
                          >
                          >
                          >> At the same time, this compromise must be traded against
                          >> the cost of reorganization and trial. As in all things, there is no
                          >> absolute, right and appropriate answer.
                          >>
                          >
                          > Exactly, you need to choose the right approach for the situation.
                          > Unfortunately, my experience is that many people have never even
                          > considered the concept that the BRUF approach might not be the
                          > greatest idea in the world, or that they have choices available to
                          > them that seem to work better in practice. Hence the article.
                          >
                          > - Scott
                          >
                          >
                          >
                          >
                          >
                          >
                          > To Post a message, send it to: scrumdevelopment@...
                          > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                          > Yahoo! Groups Links
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                        • Scott Ambler
                          I think that we need to keep a few things in mind: 1. We should be uncomfortable about the software development is just like construction analogy. I suspect
                          Message 12 of 23 , Oct 5, 2006
                            I think that we need to keep a few things in mind:
                            1. We should be uncomfortable about the software development is just
                            like construction analogy. I suspect that most people involved in the
                            discussion, either for it or against it, may know a lot about one side
                            of the equation but not much about the other. I've been exploring
                            this issue a bit, and I've found that the construction folks aren't
                            that good at planning, estimating, and even architecting buildings.
                            2. There are many people out there with their PMP who in fact are very
                            good project managers. Would they have been good PMs without a PMP?
                            Most likely.
                            3. The PMI is trying to improve. Yes, they're moving slowly. Yes,
                            they may never be as agile as we'd like. But they are trying and we
                            should do what we can to help.

                            - Scott
                          • Scott Ambler
                            ... wrote: ... say ... getting ... the ... have ... we ... That doesn t sound like FDD to me. Anyway, my heart goes out to you. - Scott
                            Message 13 of 23 , Oct 5, 2006
                              --- In scrumdevelopment@yahoogroups.com, Graeme Matthew <scrum@...>
                              wrote:

                              <snip>
                              >
                              > Then I fainted and had to go for a triple by pass when the leaders
                              say
                              > we need strong governance and control ! well lets spend $500,000
                              getting
                              > to the dev phase (i.e we start delivering working software) then
                              the
                              > vendor quotes $1.1 million to develop, so its now 1.6 why not just
                              have
                              > time and materials could have got it for 600,000 ! And then I hear
                              we
                              > are using FDD for the design and build ! so I have 324 pages as my
                              > features list :-) sure !

                              That doesn't sound like FDD to me. Anyway, my heart goes out to you.

                              - Scott
                            • mike.dwyer1@comcast.net
                              Before discounting construction analogies, you may want to look into Hal McComber s http://www.reformingprojectmanagement.com/ site and sign up for his info.
                              Message 14 of 23 , Oct 5, 2006
                                Before discounting construction analogies, you may want to look into Hal McComber's http://www.reformingprojectmanagement.com/ site and sign up for his info.
                                 
                                There is every possibility that the construction industry is ahead of us in defining, implementing and improving Agile.
                                 
                                --
                                Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


                                The greatest oak was once a little nut who held its ground. ~Author Unknown
                                 
                                -------------- Original message --------------
                                From: "Scott Ambler" <swa@...>

                                I think that we need to keep a few things in mind:
                                1. We should be uncomfortable about the software development is just
                                like construction analogy. I suspect that most people involved in the
                                discussion, either for it or against it, may know a lot about one side
                                of the equation but not much about the other. I've been exploring
                                this issue a bit, and I've found that the construction folks aren't
                                that good at planning, estimating, and even architecting buildings.
                                2. There are many people out there with their PMP who in fact are very
                                good project managers. Would they have been good PMs without a PMP?
                                Most likely.
                                3. The PMI is trying to improve. Yes, they're moving slowly. Yes,
                                they may never be as agile as we'd like. But they are trying and we
                                should do what we can to help.

                                - Scott

                              • Graeme Matthew
                                Well looking at the whole FDD handles the design and build , and actually I think the practice is very good especially for large corporates. What I am trying
                                Message 15 of 23 , Oct 6, 2006
                                  Well looking at the whole FDD handles the design and build , and
                                  actually I think the practice is very good especially for large
                                  corporates. What I am trying to do is to incorporate the Scrum
                                  principles prior to design and build. My eliminate waste is focusing on
                                  the requirements so what im leading to is:

                                  User Stories ----> Product Backlog ------> Estimation -----> Design An
                                  Overall Model ----> Build a Features List( Incorp Backlog) ---> Plan By
                                  Feature ---> Design by Feature ---> Build by Feature

                                  Their model is, spend 12 months writing bus and func spec then use FDD

                                  Its a slog !!!!

                                  Oh and by the way I got told today they chose FDD over agile :-)))))))
                                  makes you worry !
                                  Regards


                                  Graeme
                                  > That doesn't sound like FDD to me. Anyway, my heart goes out to you.
                                  >
                                  > - Scott
                                  >
                                  >
                                  >
                                  >
                                  >
                                  > To Post a message, send it to: scrumdevelopment@...
                                  > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                • Scott Ambler
                                  ... Exactly. That s definitely not FDD in the sense of http://www.featuredrivendevelopment.com/ I suspect that FDD is being used to describe the sloggish
                                  Message 16 of 23 , Oct 6, 2006
                                    --- In scrumdevelopment@yahoogroups.com, Graeme Matthew <scrum@...>
                                    wrote:
                                    >
                                    > Their model is, spend 12 months writing bus and func spec then use FDD

                                    >
                                    > Its a slog !!!!

                                    Exactly. That's definitely not FDD in the sense of
                                    http://www.featuredrivendevelopment.com/

                                    I suspect that FDD is being used to describe the "sloggish" sort of
                                    approach that you're being forced to suffer through rather than the
                                    Agile FDD described at the site above. I suspect this terminology
                                    problem may have skewed some of the results that I got in my agile
                                    survey last spring (see www.ambysoft.com/surveys/ ). Sigh.

                                    - Scott
                                  • Scott Ambler
                                    ... into Hal McComber s http://www.reformingprojectmanagement.com/ site and sign up for his info. ... It s always a good idea to read outside of IT. I ll have
                                    Message 17 of 23 , Oct 6, 2006
                                      --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
                                      >
                                      > Before discounting construction analogies, you may want to look
                                      into Hal McComber's http://www.reformingprojectmanagement.com/ site
                                      and sign up for his info.
                                      >

                                      It's always a good idea to read outside of IT. I'll have to check
                                      this out.

                                      > There is every possibility that the construction industry is ahead
                                      of us in defining, implementing and improving Agile.

                                      Perhaps, but it doesn't appear to be getting out to the construction
                                      folks. I went for lunch a couple of days ago with someone who is in
                                      the process of building a new house. He had a few choice words
                                      about the contractors, and he's dealing with a range of them, to
                                      plan and estimate their work.

                                      My former brother-in-law is a master carpenter and he's relatively
                                      agile. He considers blue prints to be interesting suggestions but is
                                      experienced enough to know when to ignore them.

                                      - Scott
                                    • Mike Dwyer
                                      Let me know what you think Scott. What areas do you read outside the sandbox we call IT? Michael F. Dwyer Planning constantly peers into the future for
                                      Message 18 of 23 , Oct 6, 2006

                                        Let me know what you think Scott.

                                         

                                        What areas do you read outside the sandbox we call IT?

                                         

                                        Michael F. Dwyer

                                         

                                        "Planning constantly peers into the future for indications as to where a solution may emerge."

                                        "A Plan is a complex situation, adapting to an emerging solution." 

                                        -----Original Message-----
                                        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Scott Ambler
                                        Sent: Friday, October 06, 2006 3:49 PM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: [scrumdevelopment] Re: Shocking the PMI Crowd a Bit

                                         

                                        --- In scrumdevelopment@ yahoogroups. com, mike.dwyer1@ ... wrote:

                                        >
                                        > Before discounting construction analogies, you may want to look
                                        into Hal McComber's http://www.reformin gprojectmanageme nt.com/ site
                                        and sign up for his info.
                                        >

                                        It's always a good idea to read outside of IT. I'll have to check
                                        this out.

                                        > There is every possibility that the construction industry is ahead
                                        of us in defining, implementing and improving Agile.

                                        Perhaps, but it doesn't appear to be getting out to the construction
                                        folks. I went for lunch a couple of days ago with someone who is in
                                        the process of building a new house. He had a few choice words
                                        about the contractors, and he's dealing with a range of them, to
                                        plan and estimate their work.

                                        My former brother-in-law is a master carpenter and he's relatively
                                        agile. He considers blue prints to be interesting suggestions but is
                                        experienced enough to know when to ignore them.

                                        - Scott

                                      • Scott Ambler
                                        ... Will do. ... I commonly read Fortune and Economist, typically for news. I also read Harvard Business Review for general business-related ideas. My wife
                                        Message 19 of 23 , Oct 6, 2006
                                          --- In scrumdevelopment@yahoogroups.com, "Mike Dwyer"
                                          <mike.dwyer1@...> wrote:
                                          >
                                          > Let me know what you think Scott.

                                          Will do.

                                          >
                                          >
                                          >
                                          > What areas do you read outside the sandbox we call IT?

                                          I commonly read Fortune and Economist, typically for news. I also
                                          read Harvard Business Review for general business-related ideas. My
                                          wife is currently back in school working on her Master of Landscape
                                          Architecture so I'm starting to read both building and landscape
                                          architecture magazines.

                                          Book wise I typically pick up things recommended to me by others,
                                          although every so often I go to the local Chapters (our version of
                                          Barnes & Noble) and browse.

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