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

Re: [XP] Software Risk - books help request

Expand Messages
  • 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 1 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 2 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 3 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.