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

RE: [scrumdevelopment] Shocking the PMI Crowd a Bit

Expand Messages
  • Bud Cookson
    Paul - some comments on your thoughts. Thanks. BUD PaulOldfield1@aol.com said on Tuesday, October 03, 2006 1:48 AM ... I
    Message 1 of 23 , Oct 3 3:46 AM
      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 2 of 23 , Oct 3 3:09 PM
        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 3 of 23 , Oct 3 3:24 PM
           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 4 of 23 , Oct 4 6:54 AM
            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 5 of 23 , Oct 4 6:58 AM
              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 6 of 23 , Oct 4 8:02 AM
                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 7 of 23 , Oct 5 2:56 AM
                  --- 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 8 of 23 , Oct 5 3:39 AM
                    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 9 of 23 , Oct 5 9:22 AM
                      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 10 of 23 , Oct 5 9:24 AM
                        --- 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 11 of 23 , Oct 5 9:56 AM
                          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 12 of 23 , Oct 6 5:11 AM
                            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 13 of 23 , Oct 6 8:24 AM
                              --- 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 14 of 23 , Oct 6 12:48 PM
                                --- 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 15 of 23 , Oct 6 2:28 PM

                                  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 16 of 23 , Oct 6 3:46 PM
                                    --- 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.