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

Re: [scrumdevelopment] Re: Scrum and risk management

Expand Messages
  • Ron Jeffries
    ... A team could do those things if they need to. If they do, they are adding to Scrum. It s best to add to an agile process ONLY when there is very good,
    Message 1 of 37 , Jun 9, 2004
    • 0 Attachment
      On Wednesday, June 9, 2004, at 1:32:28 AM, neopoxir wrote:

      > Seems to me that a review of all of the currently identified risks
      > and the strategies for addressing / mitigating / avoiding those risks
      > should occur at the start of each sprint planning meeting. That
      > would keep risk management in the forefront when identifying and
      > prioritizing features to include in the sprint backlog, and it would
      > make sure that the strategies are being carried out and updated as
      > more information becomes available. Certainly there will be cases
      > where you would want to implement more risky features early on in the
      > project in order to prove that your solution is viable or switch to
      > an alternate solution if it's not.

      > Maintaining a separate risk management matrix containing the
      > following items can be helpful:
      > - Risk type (resources | external | technical | schedule | cost |
      > operational | etc.)
      > - Risk description
      > - Risk impact (1-10)
      > - Risk probability (1-100)
      > - Risk factor (impact * probability)
      > - Management strategy (control | mitigation | avoidance) and
      > brief description of management plan

      > The impact and probability figures are admittedly subjective, but
      > they can help to highlight the current "hot" risks. Again, updating
      > and reviewing this matrix at the beginning of each sprint planning
      > meeting ensures that risks are being managed appropriately and
      > that new risks are addressed as soon as they are identified. It
      > might be useful to keep a copy of the updated risk matrix (top 10)
      > close to the burndown chart on the wall where Daily Scrum meetings
      > are held as well just to keep the team constantly thinking about
      > managing risks.

      > This approach to risk management is nothing new; Scrum just makes it
      > easier for the team to address risks quickly.

      A team could do those things if they need to. If they do, they are adding
      to Scrum. It's best to add to an agile process ONLY when there is very
      good, identified, visible reason to do so. As such, I'd not say that Scrum
      teams should always do this. I would say that they should "talk about"
      risk. And I'm sure that unless they are made up of wide-eyed dreamer
      newbies, they /do/ talk about risk, so other than a paragraph somewhere in
      the book, I'd say no more about it.

      But that's just me. I'm relentlessly agile, relentlessly into trusting the
      team. It could be a personal problem. :)

      Ron Jeffries
      www.XProgramming.com
      The central "e" in "Jeffries" is silent ... and invisible.
    • sufian abu
      A very good discussion. ... I have seen people on the extreme RIGHT who drive everything by Planning. I have also seen people on the extreme LEFT who drive
      Message 37 of 37 , Jun 11, 2004
      • 0 Attachment
        A very good discussion.
         
        Basically we have two approaches of operating:
        > By Plan
        > By Feedback
         
        I have seen people on the extreme RIGHT who drive everything by Planning. I have also seen people on the extreme LEFT who drive everything by Feedback.
         
        It is funny how people on the extreme RIGHT call the ones on the extreme LEFT cowboys and how people on the extreme LEFT call the ones on the extreme RIGHT inflexible, unrealistic, non-agile...
         
        Even though I pride in being an agilist, I base my primary approach on Feedback and then use planning techniques to supplement it.
         
        SCRUM is a very good methodology that focusses on the Feedback approach. I supplement it with XP, RUP artifacts and other organizational standard SDLC planning artifacts.
         
        It is very easy to select one of the approaches but the challenge is in using the right amount of both approaches that fits the context, the organization, the team ...
         
        Thanks,
        Sufian

        Ken Schwaber <ken.schwaber@...> wrote:
        I like the way you said this and agree. Thanks for the effort.
        Ken
        -----Original Message-----
        From: Steven Gordon [mailto:sagordon@...]
        Sent: Wednesday, June 09, 2004 1:32 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: RE: [scrumdevelopment] Re: Scrum and risk management

        We are agreeing on the what and the how, but not the why.
         
        We both agree that Scrum handles risks effectively.  We both agree on the characteristics of Scrum that enable the effective handling of risk. 
         
        You say it is because Scrum is proactive rather than reactive.  I say Scrum is neither extremely proactive nor extremely reactive, but rather balances them adapatively to the needs of each project. 
         
        Feedback and communication makes it possible to address anticipated risks in a just-in-time, proactive manner. Comapred to traditional risk management, this is less proactive, but far more efficient and effective.  Feedback and communication makes it possible to avoid premature commitments to up front solutions for plausible risks that may never actually happen during a given project.  Scrum can make adaptations to address any threatening events that do actually happen with relatively little delay and expense due to feedback, communication, and avoiding premature commitments.  This allows Scrum to react gracefully to unanticipated events. 
         
        In other words, agility allows us to be both proactive and reactive, as appriopriate to the situations that are actually occuring in a given project.  Doesn't this claim resonate well with the concepts of agility and adaptation?  Isn't this a much stronger claim than saying Scrum addresses risks proactively?
        -----Original Message-----
        From: Ken Schwaber [mailto:ken.schwaber@...]
        Sent: Wednesday, June 09, 2004 9:59 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: RE: [scrumdevelopment] Re: Scrum and risk management

        I seem to have lost track of what you are saying. You say that it "doesn't wash" but then say that frequent inspections and adaption allows agile to achieve an appropriate balance"?
        Ken

        -----Original Message-----
        From: Steven Gordon [mailto:sagordon@...]
        Sent: Wednesday, June 09, 2004 11:23 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: RE: [scrumdevelopment] Re: Scrum and risk management


        Ken,   The proactive/reactive dichotomy does not wash.   In the world where waterfall-like processes are considered best practice, the best practice for addressing risk is explicit, up front, formal risk management.  What could be more proactive than big, up-front, explicit, formal evaluation of risks and YAGNI contingency plans for those risks?   In many ways (design, requirements, planning, ...), agility is less proactive than traditional structured approaches, but less reactive than ad-hoc hacking.  Extreme proactivity has it costs in wasted time/effort and premature commitment.  Frequent inspection, communication, adaption, and delayed commitment allows agile approaches to achieve an appropriate balance between proactivity and reactivity for each project, and handle risk more appropriately than either an overly proactive or an overly reactive approach.   Steven Gordon http://sf.asu.edu/      

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







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





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





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



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