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

RE: [scrumdevelopment] Re: Shocking the PMI Crowd a Bit

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