This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
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
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.
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.
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 BoulevardNewtown Square, PA 19073-3299 USA