• 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.

11 bellds commented Permalink

@DHBernstein - I've delivered many projects. All risks are not technical risks. The risks range from business, end-user, acceptance and technical. <div>&nbsp;</div> You don't have to address ever risk before delivery because some risks are deemed acceptable to risk and not mitigate. For example, on one project there were multiple risks one of not meeting the system performance metrics, another over spending on hardware and another delivering a certain amount of functionality by a set date. We could have mitigated and resolved all risk, but we didn't. We just bought more hardware in the hope we'd meet out performance criteria. In my opinion we only really worked on reducing the delivery date risk with some migitation on the performance risk, but actually increased our budget risk. In the end - we over bought hardware. <div>&nbsp;</div> I'm sure someone got upset about the extra hardware, but the larger business goal was achieved and the sponsors were happy. <div>&nbsp;</div> Some risks are just chosen to be addressed if the risk happen post delivery. <div>&nbsp;</div> In the end - I think we agree. I think we are each talking about the opposite side of the same coin.

12 ScottAmbler commented Permalink

@BELLDS -- Good points. <br /> @DHBERSTEIN -- I suspect you've missed the point behind the Initial Operational Capability (IOC) (end of Construction) and Product Release (PR) (end of Transition) milestones in RUP. Both of these milestones address common risks which potentially occur at those points in the project, including both business risks (is the effort econically viable) and technical risks (is the system sufficiently stable for this point in time). These aren't the only risks being addressed of course. Also, although you may not agree, the article does include references to appropriate governance and the lifecycle diagram with explicit milestone reviews, both of which imply some sort of risk mitigation strategy in place.

13 DHBernstein commented Permalink

@bellds: If you identified a risk of not meeting performance requirements and explicitly decided that if necessary you would increase performance by acquiring additional hardware, then you did not leave this risk unresolved; you specified a contingency plan, a perfectly acceptable way to mitigate a risk. <div>&nbsp;</div> @Scott, I can't think of a concept more inconsistent with RUP than waiting until the end of Construction to determine whether a project is economically viable. If the current version of RUP now advocates this practice, then it's been distorted beyond recognition. Technical issues that might threaten stability must be identified and resolved by the end of Elaboration; testing conducted during every Construction iteration should verify that stability has not been compromised. With a competent team, the probability that a significant stability risk arises late in Construction should be very low. <div>&nbsp;</div> @Scott, the absence of any quantitative evidence supporting your claim that DAD "works quite well in practice" is noted.

14 ScottAmbler commented Permalink

@DHBernstein, the current version of RUP, as have previous versions of RUP, advocates that you consider the economic viability of a project at all milestone reviews. Obviously economic viability is a much greater issue early in the project, but still viable even at the end of the project. About two years ago I was asked to review a very successful RUP project which was several weeks away from release into production. The solution was technically sound, the stakeholders were happy with what had been done, the team was pretty much on schedule, and even though millions of dollars had been invested in the solution the business environment had changed so dramatically that it didn't make economic sense (or arguably political sense for that matter) to deliver the system anymore, so they "failed" the Product Release milestone on economic grounds. <div>&nbsp;</div> Quantative evidence regarding DAD is forthcoming as it takes time to gather such data. However, in the mean time, you might find http://www.ambysoft.com/surveys/ to be an interesting source of data about the effectiveness of various development paradigms and practices.

15 Mark.Lines commented Permalink

@DHBernstein There are some fundamental aspects of RUP you should do some more research on. <div>&nbsp;</div> 2) Actually, very little Requirements related risk is mitigated in Inception. You have very little requirements detail at this point (1-20 pages, the less the better). Requirements risk is not mitigated in any material way until the Elaboration iterations when the stakeholders start to see working increments of software, and start to fully understand what they truly require. <div>&nbsp;</div> And it is unusual to write code in Inception. It may be worthwhile if a technical proof-of-concept is required to prove out the business case feasibility, or to do some UI prototyping. However, agile modeling is a quicker way to elicit UI info than writing code, and doesn't give the customers a false impression of progress. <div>&nbsp;</div> Might I suggest that you read one of the many books that Ambler has written on RUP before you lecture him on what it is.

Add a Comment Add a Comment