• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (25)

1 DHBernstein commented Permalink

You have completely ignored the critical notion of identifying and mitigating risk before making large investments in implementation.

2 ScottAmbler commented Permalink

I guess I didn't go into enough detail. Sorry about that, here are some thoughts: <br /> 1. In my Agile lifecycle article at http://www.ambysoft.com/essays/agileLifecycle.html I discuss a "pre-project" phase (iteration -1, project selection, whatever you want to call it) where some initial reality checking such as you imply would occur. Well, hopefully occur. ;-) This phase is purposely outside the scope of DAD although there is the assumption that something like this has occurred. <br /> 2. As part of architecture envisioning, http://www.agilemodeling.com/essays/initialArchitectureModeling.htm , during Inception, the team would consider technical risks and do their best to think through and identify appropriate strategies to mitigate the problems. <br /> 3. The goal of the "proven architecture" milestone of Figures 2&amp;3 is to prove that your architectural strategy addresses your technical constraints, requirements, and risks. You do this by building an end-to-end skeleton of the system which implements critical "technically risk" requirements in the first iteration or so of construction (for complex systems, it could take several iterations, stuff happens). This is a strategy straight out of the Unified Process, adopted by Agile Modeling and by DAD. I describe the strategy at http://www.agilemodeling.com/essays/agileArchitecture.htm#ProveIt . <div>&nbsp;</div> I will blog about the milestones in the near future, as they are major aspects of risk mitigation in DAD. Maybe I'll blog about risk mitigation in general, haven't decided yet. Please stay tuned!

3 Mark.Lines commented Permalink

In RUP, we have a Phase called Elaboration that focuses on derisking the project through constructing increments of software to prove out the architecture and mitigate other risks such as those related to requirements uncertainty and schedule. Unfortunately, I have seen over and over again supposed "RUP" projects that do not understand that we are constructing in Elaboration. Instead, they see just do requirements and/or design activities in Elaboration. They wait until Construction to start building software. This is NOT RUP! Some people have called these types of anti-patterns "RUP In Name Only (RINO)". We want to ensure that don't end up with "Agile in Name Only". <div>&nbsp;</div> To avoid confusion, DAD has removed the explicit Elaboration Phase, but there is still guidance in DAD that specifically recommends addressing risk early. This is described in the "Risk-Value Lifecycle" practice. While the Elaboration Phase is gone, Scott shows the milestone of "Proven Architecture", accomplished in the early Construction iterations. The emphase on a risk-value approach vs. merely value-driven approach is a differentiator between core agile methods such as Scrum, and the Disiciplined approach of DAD. <div>&nbsp;</div> Removing Elaboration as a phase has caused some heartburn for RUP fans. Even I had to give it some thought before I bought into this approach. But I have come to the conclusion that this is absolutely the right approach. The DAD phases makes it extremely clear that we start building software immediately upon completing Inception, consistent with other agile approaches of Iteration 1. <div>&nbsp;</div> If you are interested in learning more about how DAD takes core agile methods to the next level, with an appropriate minimalist approach to necessary governance, agile modiling and other disciplines, you may be interested in IBM's new 2-day DAD workshop (course code RP250).

4 T5PS_david_meltzer commented Permalink

Is DAD available as a method plug-in for RMC?

5 ScottAmbler commented Permalink

David, good question. At the present moment there is no plug in for DAD. <div>&nbsp;</div> We have not announced, either way, any work for DAD support in RMC. If we do I will post to this blog.

6 DHBernstein commented Permalink

1. "Risk Mitigation" is not a detail; it's a fundamental driver. <div>&nbsp;</div> 2. In RUP, risk is identified and mitigated during Inception (requirements risk) and Elaboration (technical risk), not just during Elaboration. Code-producing iterations begin during Inception. <div>&nbsp;</div> 3. Removing Elaboration because some projects don't properly employ it is ridiculous. Will you be removing functional testing because some projects do it poorly?

7 ScottAmbler commented Permalink

DH, I meant that it was a detail in the sense that I wrote a 1,000 word blog posting which overviews the lifecycle and not a 250-page book overviewing the method. <div>&nbsp;</div> Actually, in RUP risk is mitigated throughout the entire lifecycle, not just during the Inception and Elaboration phases. All four phases have milestones which reflect some aspects of risk management, although there is more to risk management in RUP than just milestone reviews. Risk mitigation is also an important aspect throughout the entire lifecycle of DAD as well. <div>&nbsp;</div> In DAD we've kept the important aspects of UP's Elaboration phase of proving the architecture with working code but streamlined the overall lifecycle by removing the explicit phase. We've found this to work quite well in practice.

8 DHBernstein commented Permalink

By failing to mention risk once in your 1000-word overview and then characterizing risk mitigation as a "detail" when this was pointed out, you make it clear that you don't consider risk mitigation to be important -- in stark contrast with RUP, where risk identification and mitigation are primary drivers. <div>&nbsp;</div> In RUP, the goal is to eliminate all risk by the end of Elaboration, enabling the team to commit to the satisfaction of all release criteria by a specified date. Intentionally allowing risks to remain unmitigated into Construction or beyond is generally a mistake. <div>&nbsp;</div> How many projects of what scope by organizations with what experience-level have been completed with DAD? What metrics from these projects lead you to claim that it "works quite well in practice"?

9 bellds commented Permalink

I have yet to have a project that can successfully drive out all risk. Risk is something you deal with through the project not just the early stages. <div>&nbsp;</div> I've also come to the conclusion - No Risk = No Reward. Afterall, if there is no risk everyone would be doing it.

10 DHBernstein commented Permalink

"I have yet to have a project that can successfully drive out all risk" can only mean that you have never delivered, since by definition all risk has been eliminated at delivery. The variable is how far into the project lifecycle one proceeds before eliminating all significant risks. RUP advocates the elimination of all significant requirements and technical risk by the end of its Elaboration phase. <div>&nbsp;</div> Employing risk identification and mitigation as a driver does not mean "don't take risks"; risk is a natural byproduct of innovation and differentiation. The idea is to identify and resolve risks early before making large investments in implementation and before making hard delivery commitments. A team that's competent at risk mitigation can successfully undertake more innovative, novel, and differentiated projects because they can effectively deal with the higher levels of risk associated with such projects.

Add a Comment Add a Comment