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

Re: lack of pre-project phase & What is "Done"?

Expand Messages
  • David A Barrett
    While I can see the value in some degree of pre-project work, I wonder if there isn t a fundamental clash between Scrum and some of these pre-project
    Message 1 of 4 , Oct 12, 2004
      While I can see the value in some degree of pre-project work, I wonder if
      there isn't a fundamental clash between Scrum and some of these pre-project
      activities.

      Particularly problematic would be tendency to define when the project will
      be "done" in the pre-project phase. While, on its face, this seems to make
      sense it ignores the fact that things will be learned during the course of
      the Sprints and definition of "done" may undergo a radical change as a
      result. Of course, this also makes it difficult to determine other things,
      such as "when" the project will be done, or what kind of budget it would
      require.

      I like the idea of a pre-project "spike". I can see such a spike having
      the following goals:

      1. Clear statement of the BUSINESS goals of the project. Remember,
      business goals are never "To build a system that will...".
      2. Gather ideas and impressions from the user community.
      3. Compile a prelimary Product Backlog (with very, very large
      granularity).
      4. Assign some OOM cost/time estimates to the PB items.
      5. Address to some degree the idea of a release date or dates.

      Which I understand all feels a little "fast and loose" for most large
      corporations. I wonder what the reception would be if you were to couple
      it with a formal "3rd Sprint Project Review", where they would re-asses the
      feasibility, costs and delivery dates. It seems to me that some companies
      spend months doing studies, project planning and other "non-productive"
      pre-project stuff that really doesn't do much more than provide CYA for the
      people approving the project. If that were to be replaced by a pre-project
      spike, three sprints and a review, not only would they probably have
      learned as much as they would traditionally have learned, they'd have 3
      months worth of productive development completed.


      Dave Barrett,
      Lawyers' Professional Indemnity Company
    • todd
      ... It s all related which makes it hard. People want to know when it will be done and how much it will cost before they commit. This is reasonable. Yet you
      Message 2 of 4 , Oct 12, 2004
        David A Barrett wrote:

        > Particularly problematic would be tendency to define when the project will
        > be "done" in the pre-project phase. While, on its face, this seems to
        > make
        > sense it ignores the fact that things will be learned during the course of
        > the Sprints and definition of "done" may undergo a radical change as a
        > result. Of course, this also makes it difficult to determine other
        > things,
        > such as "when" the project will be done, or what kind of budget it would
        > require.

        It's all related which makes it hard. People want to know when it will
        be done and how
        much it will cost before they commit. This is reasonable. Yet you can't
        really know this
        until you are done. You know more at various points but you can always have
        a last minute show stopper. My reasonable expectation is you do the best you
        can and then be willing to adjust later, but this isn't always good enough.

        >
        > Which I understand all feels a little "fast and loose" for most large
        > corporations.

        I don't know if size is the determining factor. It's anyone who is
        commiting scarce resources
        to a project. If you aren't the one commiting resources (credibility,
        time, money, etc) it's easy
        to underestimate the weight this part has in your decision making.

        > I wonder what the reception would be if you were to couple
        > it with a formal "3rd Sprint Project Review", where they would
        > re-asses the
        > feasibility, costs and delivery dates. It seems to me that some companies
        > spend months doing studies, project planning and other "non-productive"
        > pre-project stuff that really doesn't do much more than provide CYA
        > for the
        > people approving the project.

        CYA is a social force that is easy to make fun of, yet is as real as a
        bullet, and can't be ignored.

        > If that were to be replaced by a pre-project
        > spike, three sprints and a review, not only would they probably have
        > learned as much as they would traditionally have learned, they'd have 3
        > months worth of productive development completed.

        If your scenario is that it takes 3 months to make a decision then it
        looks better. How about if
        we time box it for 2 weeks? Then is it a reasonable phase? Would it be
        better than hiring 10
        people and then firing them 3 iterations later when you figure out you
        are stuck? A lot of
        factors are involved....
      • Steven Gordon
        The iterative nature of a Scrum project allows the money people to periodically decide whether the project still has potential to produce sufficient ROI for
        Message 3 of 4 , Oct 12, 2004
          The iterative nature of a Scrum project allows the money people to periodically
          decide whether the project still has potential to produce sufficient ROI for the
          cost and risk. This means to start a project, the business case does not need
          to be so air-tight with a precise definition of the deliverables and their schedule,
          but rather just enough due diligence to determine if the costs and risks are worth
          the potential gain (given that the decision can be revisited periodically).

          This means the company can save a lot of time and money on pre-project
          analyses that the project team often has to redo anyway. It also means that if
          the market or political assumptions change, the project can be cancelled or
          re-directed with minimal cost.

          This is why I like to start a project with a single small team (sometimes just a
          single pair), and then use mitosis to scale up if the customer is happy with the
          early results and wants to invest more resources to get more results faster.

          For an agile project, the most important part of the chartering phase is not a
          CYA business case, but rather discovering all the stakeholders and getting them
          on board. This is also important for non-agile projects, but not as important as
          the business case, because changing the direction of a non-agile project is much
          more expensive, partly because so much more has been invested in the
          pre-project study.

          Steven Gordon
          http://sf.asu.edu/



          -----Original Message-----
          From: David A Barrett [mailto:dave.barrett@...]
          Sent: Tue 10/12/2004 10:04 AM
          To: scrumdevelopment@yahoogroups.com
          Cc:
          Subject: [scrumdevelopment] Re: lack of pre-project phase & What is "Done"?






          While I can see the value in some degree of pre-project work, I wonder if
          there isn't a fundamental clash between Scrum and some of these pre-project
          activities.

          Particularly problematic would be tendency to define when the project will
          be "done" in the pre-project phase. While, on its face, this seems to make
          sense it ignores the fact that things will be learned during the course of
          the Sprints and definition of "done" may undergo a radical change as a
          result. Of course, this also makes it difficult to determine other things,
          such as "when" the project will be done, or what kind of budget it would
          require.

          I like the idea of a pre-project "spike". I can see such a spike having
          the following goals:

          1. Clear statement of the BUSINESS goals of the project. Remember,
          business goals are never "To build a system that will...".
          2. Gather ideas and impressions from the user community.
          3. Compile a prelimary Product Backlog (with very, very large
          granularity).
          4. Assign some OOM cost/time estimates to the PB items.
          5. Address to some degree the idea of a release date or dates.

          Which I understand all feels a little "fast and loose" for most large
          corporations. I wonder what the reception would be if you were to couple
          it with a formal "3rd Sprint Project Review", where they would re-asses the
          feasibility, costs and delivery dates. It seems to me that some companies
          spend months doing studies, project planning and other "non-productive"
          pre-project stuff that really doesn't do much more than provide CYA for the
          people approving the project. If that were to be replaced by a pre-project
          spike, three sprints and a review, not only would they probably have
          learned as much as they would traditionally have learned, they'd have 3
          months worth of productive development completed.


          Dave Barrett,
          Lawyers' Professional Indemnity Company



          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



          Yahoo! Groups Sponsor
          ADVERTISEMENT
          click here <http://us.ard.yahoo.com/SIG=129crltkq/M=294855.5468653.6549235.3001176/D=groups/S=1707209021:HM/EXP=1097687104/A=2376776/R=0/SIG=11ldm1jvc/*http://promotions.yahoo.com/ydomains2004/index.html>
          <http://us.adserver.yahoo.com/l?M=294855.5468653.6549235.3001176/D=groups/S=:HM/A=2376776/rand=585430807>


          _____

          Yahoo! Groups Links


          * To visit your group on the web, go to:
          http://groups.yahoo.com/group/scrumdevelopment/

          * To unsubscribe from this group, send an email to:
          scrumdevelopment-unsubscribe@yahoogroups.com <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>

          * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
        • Michael Spayd
          Thanks to those who have contributed so far on this thread. This is very useful for my own thinking. My experience has been there is a huge gap between agile
          Message 4 of 4 , Oct 13, 2004
            Thanks to those who have contributed so far on this thread. This is
            very useful for my own thinking. My experience has been there is a
            huge gap between agile develoment methods and the work done around
            them in terms of governance and funding, which are still very old
            school.

            I haven't had time to formulate my thoughts, but wanted to acknowledge
            my appreciation for y'alls thoughts.

            Michael


            --
            Michael K. Spayd
            COGILITY, llc
            "Business Mind, Social Heart"
            michael.spayd@...
            720.300.5286
          Your message has been successfully submitted and would be delivered to recipients shortly.