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

Re: [XP] Software Risk - books help request

Expand Messages
  • Marco Bizzarri
    My quote was somewhat incomplete. I did it on the top of my memory; I m writing from the book, now: (( page 187, talking about Planning Extreme Programming ))
    Message 1 of 18 , Sep 1, 2008
    View Source
    • 0 Attachment
      My quote was somewhat incomplete. I did it on the top of my memory;
      I'm writing from the book, now:

      (( page 187, talking about Planning Extreme Programming ))

      "When viewed as a set of RM (( not sure if he means Risk Management or
      Risk Mitigation )) stratedies, XP makes all kinds of sense. The
      two-week planning and delivery cycle determined by the customer is a
      built-in risk-mitigation strategy with customer-defined value and is
      designed to prevent late delivery."

      I think we are talking more about risk-mitigation, therefore.

      Regards
      Marco

      On Sun, Aug 31, 2008 at 8:18 PM, paul grew <paul.grew@...> wrote:
      > what risk management tools does XP have?
      >
      > 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@...
      >> <mailto:extremeprogramming%40simonkirk.com>> 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://notenotturne.blogspot.com/>
      >> http://iliveinpisa.blogspot.com/ <http://iliveinpisa.blogspot.com/>
      >>
      >>
      >
      > --
      >
      > <http://11thhourfilm.com>
      >
      >



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