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

Re: [scrumdevelopment] Shocking the PMI Crowd a Bit

Expand Messages
  • 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 1 of 23 , Oct 3, 2006
    View Source
    • 0 Attachment
      (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 2 of 23 , Oct 3, 2006
      View Source
      • 0 Attachment
        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 3 of 23 , Oct 3, 2006
        View Source
        • 0 Attachment
          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 4 of 23 , Oct 3, 2006
          View Source
          • 0 Attachment
            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 5 of 23 , Oct 3, 2006
            View Source
            • 0 Attachment
               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 6 of 23 , Oct 4, 2006
              View Source
              • 0 Attachment
                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 7 of 23 , Oct 4, 2006
                View Source
                • 0 Attachment
                  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 8 of 23 , Oct 4, 2006
                  View Source
                  • 0 Attachment
                    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 9 of 23 , Oct 5, 2006
                    View Source
                    • 0 Attachment
                      --- 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 10 of 23 , Oct 5, 2006
                      View Source
                      • 0 Attachment
                        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 11 of 23 , Oct 5, 2006
                        View Source
                        • 0 Attachment
                          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 12 of 23 , Oct 5, 2006
                          View Source
                          • 0 Attachment
                            --- 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 13 of 23 , Oct 5, 2006
                            View Source
                            • 0 Attachment
                              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 14 of 23 , Oct 6, 2006
                              View Source
                              • 0 Attachment
                                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 15 of 23 , Oct 6, 2006
                                View Source
                                • 0 Attachment
                                  --- 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 16 of 23 , Oct 6, 2006
                                  View Source
                                  • 0 Attachment
                                    --- 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 17 of 23 , Oct 6, 2006
                                    View Source
                                    • 0 Attachment

                                      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 18 of 23 , Oct 6, 2006
                                      View Source
                                      • 0 Attachment
                                        --- 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.