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

Re: [XP] Software Risk - books help request

Expand Messages
  • Ken Boucher
    ... project. ... I would like to add to this list the following additions. An XP project has more points in time for the customer to halt investment. Having
    Message 1 of 18 , Sep 3, 2008
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Steven Gordon"
      <sgordonphd@...> wrote:

      > XP itself mitigates many major risks:
      >
      > Here are some examples:
      > * Sustainable Pace reduces the chance of somebody leaving during the
      project.
      > * Pair programming and Collective Code Ownership reduces the impact if
      > somebody does leave during the project.
      > * Test Driven Development, Automated Acceptance Tests and Continuous
      > Integration sharply reduces the half-life of bugs.
      > * Frequent Delivery of working software and On-site Customer reduces
      > the chance of developing the wrong software.
      > * Frequent Delivery of working software reduces the chance of being
      > surprised at what will be delivered on the due date.
      > * Frequent Delivery of working software guarantees that working
      > software will be available on the due date.
      >
      > Come to think of it, frequent feedback based on the frequent
      > delivery of working software is the best possible risk management
      > tool, because if we pay attention, we will see risks coming and be
      > able to plan for the ones that are coming using the current
      > information at the time.
      >
      > Compare this to the alternate approach of trying to anticipate all
      > possible risks and preparing a plan for each risk at the beginning
      > of the project when we have the least accurate information we will
      > ever have during the project. Planning for risks that will never
      > happen is a big waste of time and effort. Making plans for those
      > risks based on information that will be inaccurate when the risks
      > actually happen is a big waste of time and effort.

      I would like to add to this list the following additions.

      An XP project has more points in time for the customer to halt
      investment. Having the information to make a decision to suspend or
      stop a project at two months instead of six months may result in
      substantial savings.

      In addition, when that investment is halted, the customer does have a
      working something. It may not be enough of a something to be
      profitable and useful or it may be. And even if it's not completed
      enough when a project is halted, it's often in a state where it can be
      restarted with minimal waste (for some definitions of waste).

      The ability to save by stopping a failed project sooner, having a
      product to show for the money that was invested, and being able to
      restart from a product with shippable tested functionality, all serve
      to manage risk from a mitigation standpoint.
    • paul grew
      i agree with everything everyone has said about risk mitigation and Steven s comment about not bothering to mitigate irrelevant risks is a great example of
      Message 2 of 18 , Sep 3, 2008
      • 0 Attachment
        i agree with everything everyone has said about risk mitigation and
        Steven's comment about not bothering to mitigate irrelevant risks is a
        great example of YAGNI.
        but if the traditional approach to risk analysis is
        get a list of typical project risks
        add some of your own
        work out the probability of each occurring
        work out the impact for each
        design a plan for how to avoid it or what to do if it happens
        then forget about it (excuse my sarcasm)

        then what's the agile or XP approach? is this what folks do?
        brainstorm what would really screw up the project
        add some tasks to the release plan or change some behaviour of the team
        repeat based on feed back each iteration


        Ken Boucher wrote:
        >
        > --- In extremeprogramming@yahoogroups.com
        > <mailto:extremeprogramming%40yahoogroups.com>, "Steven Gordon"
        > <sgordonphd@...> wrote:
        >
        > > XP itself mitigates many major risks:
        > >
        > > Here are some examples:
        > > * Sustainable Pace reduces the chance of somebody leaving during the
        > project.
        > > * Pair programming and Collective Code Ownership reduces the impact if
        > > somebody does leave during the project.
        > > * Test Driven Development, Automated Acceptance Tests and Continuous
        > > Integration sharply reduces the half-life of bugs.
        > > * Frequent Delivery of working software and On-site Customer reduces
        > > the chance of developing the wrong software.
        > > * Frequent Delivery of working software reduces the chance of being
        > > surprised at what will be delivered on the due date.
        > > * Frequent Delivery of working software guarantees that working
        > > software will be available on the due date.
        > >
        > > Come to think of it, frequent feedback based on the frequent
        > > delivery of working software is the best possible risk management
        > > tool, because if we pay attention, we will see risks coming and be
        > > able to plan for the ones that are coming using the current
        > > information at the time.
        > >
        > > Compare this to the alternate approach of trying to anticipate all
        > > possible risks and preparing a plan for each risk at the beginning
        > > of the project when we have the least accurate information we will
        > > ever have during the project. Planning for risks that will never
        > > happen is a big waste of time and effort. Making plans for those
        > > risks based on information that will be inaccurate when the risks
        > > actually happen is a big waste of time and effort.
        >
        > I would like to add to this list the following additions.
        >
        > An XP project has more points in time for the customer to halt
        > investment. Having the information to make a decision to suspend or
        > stop a project at two months instead of six months may result in
        > substantial savings.
        >
        > In addition, when that investment is halted, the customer does have a
        > working something. It may not be enough of a something to be
        > profitable and useful or it may be. And even if it's not completed
        > enough when a project is halted, it's often in a state where it can be
        > restarted with minimal waste (for some definitions of waste).
        >
        > The ability to save by stopping a failed project sooner, having a
        > product to show for the money that was invested, and being able to
        > restart from a product with shippable tested functionality, all serve
        > to manage risk from a mitigation standpoint.
        >
        >

        --

        <http://11thhourfilm.com>
      • kentb
        Dear Paul, The strategy you outline below seems like a reasonable idea. It should be possible to do this in a way that harmonizes with XP. The problems I can
        Message 3 of 18 , Sep 3, 2008
        • 0 Attachment
          Dear Paul,

          The strategy you outline below seems like a reasonable idea. It should be
          possible to do this in a way that harmonizes with XP. The problems I can
          imagine would come if risk management were done contrary to the values of
          XP. For example, if you were so worried about risks that you sat around
          thinking about them for a long time instead of going out and getting
          experience with them (and, hopefully, eliminating the cheap ones).

          Regards,

          Kent Beck
          Three Rivers Institute

          _____

          From: extremeprogramming@yahoogroups.com
          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of paul grew
          Sent: Wednesday, September 03, 2008 10:59 AM
          To: extremeprogramming@yahoogroups.com
          Subject: Re: [XP] Software Risk - books help request



          i agree with everything everyone has said about risk mitigation and
          Steven's comment about not bothering to mitigate irrelevant risks is a
          great example of YAGNI.
          but if the traditional approach to risk analysis is
          get a list of typical project risks
          add some of your own
          work out the probability of each occurring
          work out the impact for each
          design a plan for how to avoid it or what to do if it happens
          then forget about it (excuse my sarcasm)

          then what's the agile or XP approach? is this what folks do?
          brainstorm what would really screw up the project
          add some tasks to the release plan or change some behaviour of the team
          repeat based on feed back each iteration

          Ken Boucher wrote:
          >
          > --- In extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
          yahoogroups.com
          > <mailto:extremeprogramming%40yahoogroups.com>, "Steven Gordon"
          > <sgordonphd@...> wrote:
          >
          > > XP itself mitigates many major risks:
          > >
          > > Here are some examples:
          > > * Sustainable Pace reduces the chance of somebody leaving during the
          > project.
          > > * Pair programming and Collective Code Ownership reduces the impact if
          > > somebody does leave during the project.
          > > * Test Driven Development, Automated Acceptance Tests and Continuous
          > > Integration sharply reduces the half-life of bugs.
          > > * Frequent Delivery of working software and On-site Customer reduces
          > > the chance of developing the wrong software.
          > > * Frequent Delivery of working software reduces the chance of being
          > > surprised at what will be delivered on the due date.
          > > * Frequent Delivery of working software guarantees that working
          > > software will be available on the due date.
          > >
          > > Come to think of it, frequent feedback based on the frequent
          > > delivery of working software is the best possible risk management
          > > tool, because if we pay attention, we will see risks coming and be
          > > able to plan for the ones that are coming using the current
          > > information at the time.
          > >
          > > Compare this to the alternate approach of trying to anticipate all
          > > possible risks and preparing a plan for each risk at the beginning
          > > of the project when we have the least accurate information we will
          > > ever have during the project. Planning for risks that will never
          > > happen is a big waste of time and effort. Making plans for those
          > > risks based on information that will be inaccurate when the risks
          > > actually happen is a big waste of time and effort.
          >
          > I would like to add to this list the following additions.
          >
          > An XP project has more points in time for the customer to halt
          > investment. Having the information to make a decision to suspend or
          > stop a project at two months instead of six months may result in
          > substantial savings.
          >
          > In addition, when that investment is halted, the customer does have a
          > working something. It may not be enough of a something to be
          > profitable and useful or it may be. And even if it's not completed
          > enough when a project is halted, it's often in a state where it can be
          > restarted with minimal waste (for some definitions of waste).
          >
          > The ability to save by stopping a failed project sooner, having a
          > product to show for the money that was invested, and being able to
          > restart from a product with shippable tested functionality, all serve
          > to manage risk from a mitigation standpoint.
          >
          >

          --

          <http://11thhourfilm <http://11thhourfilm.com> .com>






          [Non-text portions of this message have been removed]
        • Doug Swartz
          ... One of the risk mitigation strategies we learned as part of our initial foray into XP land is: Worst things first . In other words, if there are things
          Message 4 of 18 , Sep 3, 2008
          • 0 Attachment
            Wednesday, September 03, 2008, 12:59:16 PM, paul grew wrote:

            > i agree with everything everyone has said about risk mitigation and
            > Steven's comment about not bothering to mitigate irrelevant risks is a
            > great example of YAGNI.
            > but if the traditional approach to risk analysis is
            > get a list of typical project risks
            > add some of your own
            > work out the probability of each occurring
            > work out the impact for each
            > design a plan for how to avoid it or what to do if it happens
            > then forget about it (excuse my sarcasm)

            > then what's the agile or XP approach? is this what folks do?
            > brainstorm what would really screw up the project
            > add some tasks to the release plan or change some behaviour of the team
            > repeat based on feed back each iteration

            One of the risk mitigation strategies we learned as part
            of our initial foray into XP land is: "Worst things first".
            In other words, if there are things that we feel are risky to
            the project, deal with them first, which leads to the risk
            limitation strategy we talk about, known as "fail early". If
            the project is going to fail, let's do it as early as
            possible, so we don't waste all of our money, just some of it.

            I've always felt you need to do some version of the first four
            things on your list to be able to know what is the "worst"
            thing, so you can deal with it. Every project I've been on
            could list its big risks with a reasonable sense of each's
            likelihood and probable worst case impact with less than a
            day's worth of effort.

            Somewhere near the middle of the page at
            http://c2.com/cgi/wiki?WorstThingsFirst Kent has a nice short
            summary that reminds us the "worst", and riskiest things are
            often not strictly technical in nature. We forget this at our
            own peril.

            Doug Swartz
          Your message has been successfully submitted and would be delivered to recipients shortly.