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

Re: [XP] Software Risk - books help request

Expand Messages
  • Marco Bizzarri
    On Sun, Aug 31, 2008 at 9:32 PM, Simon Kirk ... Mumble mumble... my days in statistical and probabilistic analysys are very far in the past ;),but I felt that
    Message 1 of 18 , Sep 1, 2008
      On Sun, Aug 31, 2008 at 9:32 PM, Simon Kirk
      <extremeprogramming@...> wrote:
      > David, Marco, thanks for the pointers.
      >
      > Marco: I haven't read the book yet unfortunately. The reviews seemed
      > to indicate:
      >
      > 1. A lack of rigourous mathematical examination of the Risk strategies
      > in the book (personally I think that would be massive overkill)

      Mumble mumble... my days in statistical and probabilistic analysys are
      very far in the past ;),but I felt that the maths was enough for the
      purpose of the book.


      > 2. While the book mentions Agile, it doesn't examine in detail how it
      > mitigates the Risks mentioned in the book.

      I think they are too critics on this topic. The book is less than 200
      hundred pages long, and, it tries to address the problem. If I could
      make a parallel, this is not the GoF for RM.

      > I don't see 1 or 2 as disastrous, but not having read the book yet I
      > don't even know if 1 and 2 are accurate.

      Please share your thoughts with us when you read the book.

      > Cheers,
      > Simon
      >
      > On 31 Aug 2008, at 12:41, Marco Bizzarri wrote:
      >
      >> I read the book maybe two years ago; I liked it a lot.
      >>
      >> It proposes a method which should be adaptable enough to be used in
      >> many contexts.
      >>
      >> It has a bibliography on Risk Management topic; you cannot apply it
      >> directly to XP or Agile, I think, but it acknowledge XP has inherently
      >> built-in risk management tools, so that it can be easily adapted to
      >> it.
      >>
      >>
      >> I wonder what are the things missing from this book. Can you share
      >> some thoughts?
      >>
      >> Regards
      >> Marco
      >>
      >>
      >>
      >> On Sun, Aug 31, 2008 at 1:26 PM, Simon Kirk
      >> <extremeprogramming@...> wrote:
      >>> Hi all.
      >>>
      >>> Since my stack of Agile/Lean/etc books to read has recently got
      >>> dangerously close to less than six feet tall, I thought I would add a
      >>> few more. One area in particular I'm interested in learning more
      >>> about
      >>> is software Risk management.
      >>>
      >>> Having read Slack already, and loving Lister & DeMarco's style (I
      >>> know
      >>> Slack was only by Tom DeMarco, but still), I thought I would grab a
      >>> copy of Waltzing with Bears.
      >>>
      >>> Having a brief look through the reviews on Amazon (and applying the
      >>> usual pinch of salt), some reviews on the UK site (I'm in the UK)
      >>> seemed to indicate that WwB was lacking a few things. The US site's
      >>> reviews were a bit more positive, but still it made me take notice.
      >>>
      >>> Can anybody back this up or deny it? I'm going to read the book
      >>> anyway, but I'm open to suggestions of other resources to read to
      >>> learn more about risk in software, too.
      >>>
      >>> Cheers for any help.
      >>> Simon
      >>>
      >>> [|]
      >>>
      >>>
      >>
      >>
      >>
      >> --
      >> Marco Bizzarri
      >> http://notenotturne.blogspot.com/
      >> http://iliveinpisa.blogspot.com/
      >>
      >> ------------------------------------
      >>
      >> To Post a message, send it to: extremeprogramming@...
      >>
      >> To Unsubscribe, send a blank message to:
      >> extremeprogramming-unsubscribe@...
      >>
      >> ad-free courtesy of objectmentor.comYahoo! Groups Links
      >>
      >>
      >>
      >
      > [|]
      >
      >



      --
      Marco Bizzarri
      http://notenotturne.blogspot.com/
      http://iliveinpisa.blogspot.com/
    • 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 2 of 18 , Sep 3, 2008
        --- 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 3 of 18 , Sep 3, 2008
          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 4 of 18 , Sep 3, 2008
            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 5 of 18 , Sep 3, 2008
              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.