This is the governing body for certification in Disciplined Agile.

Address Risk

  • 22 Aug 2018 8:07 AM
    Reply # 6633770 on 6404459
    Scott Ambler (Administrator)


    • We've already indicated different risk types, or sources of risk, via the Explore Risks decision point.


    • I like the point about context.  Will update the chapter with this concept.
    • Good point about tech debt, will make it clear.
    • Great point about requirements debt and working iteratively.
    • I like the idea of infinite risks. Similarly with creeping risk now that I think about it.
    • Shift left - I like it!
  • 04 Aug 2018 11:09 AM
    Reply # 6413334 on 6404459

    Reasons: context specific & leverage experience  

    We could have experience with our domain or our development, but the context - product, release or unexpected events - can induce specific risks that need specific responses. In the same time, if we have experience, we can leverage this experience to avoid some of the risks. 


    If I will need to give just a summary guidance about software development main risks, I will include

    • Leverage your experience, but consider the specific context
    • Analyse technical debt impact
    • Validate your requirements iteratively (…if you really want to progress to a consumable solution)
    • When address risks try first to avoid and shift left
    • Beware of “infinite risks


    Explore Risks - Architectural, Technical debt  

    Maybe it is already included in the referenced sections, but it is a basic aspect of software-related risks: technical debt. We need to asses the technical debt for the software parts involved in the current development cycle because we will need a strategy to deal with it.     

    Why is it important? Technical debt is known top risk in software development. Also, this risk does not decrease, but it is accumulating and could exponentially increase. For risks and software development, technical debt is always in the first two or three things that come to my mind.

    Explore Risks - Requirements, Addressing complexity by validating requirements iteratively  

    That is fundamental imo; it is a part of Agile & Lean intentions and DAD has best set of practices to deal with.  We have here “and then allow the details to evolve via the Address Changing Stakeholder Needs process goal (Chapter XX).”

    With “Addressing Changing Stakeholders Needs” and “Active Stakeholders Participations” (and others) Agile and DAD – beyond gathering the details – will reduce the complexity by validating the requirements iteratively and often feedback. Complexity is one of the main problems to manage and validating and gathering the requirements right is a significant aspect. 


    Classify Risks – Qualitative Analysis

    “Some risks are hard to quantify and are more subjective in nature”. We should take care of “infinite risks”, hard to be quantified with numbers, that could completely nullify our work result. Example: impossible to get the needed quality or performance, impossible to get a feasible solution.   


    Address risks – Avoid and Shift Left

    This is also fundamental; Instead of “…Although this is often earlier rather than later …” I propose to use “…Although this is often earlier (avoid and/or “shift left”) rather than later …

    If I have only five words to tell about risks, I will use these ones.

  • 30 Jul 2018 3:56 PM
    Reply # 6405618 on 6404459

    Hi Scott

    I recall from the ISTQB curriculum, they went to great lengths to make the distinction between "Project Risks" and "Product Risks" (this thinking could also then be extended to include "Service Risks" or "Solution Risks"). 

    I do not think we need to be that pedantic, but just wanted to run it past you to ensure that we may not have missed something. Personally I do not think the distinction is important, but you may get some ISTQB views that may want the distinction. 



  • 30 Jul 2018 7:50 AM
    Message # 6404459
    Scott Ambler (Administrator)

    We've just published the initial draft of the Address Risk process goal chapter.  

    Note: We've merged the goal Identify Risks into this one to simplify the DAD portion of the framework.

    Looking forward to your feedback!

© 2013-2019 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software