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

16 DHBernstein commented Permalink

@Scott, the "very successful RUP project" you describe was an epic failure. The possibility of a dramatic change in business environment should have been anticipated during Inception and updated during Elaboration, with appropriate checkpoints and contingency plans established to take evasive action if warranted. Spending millions and getting all the way to end-of-Construction before discovering that the project no longer makes economic sense is what RUP was designed to avoid. <div>&nbsp;</div> I understand that it takes time to acquire reliable quantitative data that substantiates process improvements. Until you've accomplished this, however, responses of the form "works quite well in practice" are tantamount to hand-waving; more substantive arguments are expected.

17 DHBernstein commented Permalink

@Mark, Inception's objective is to understand and agree upon scope. As described on page 64 of "The Rational Unified Process, an Introduction", this requires "Discriminating the critical use cases of the system - that is, the primary scenarios of behavior that will drive system's functionality and will shape the major design tradeoffs". One cannot claim to have identified a system's critical use cases until all significant requirements risk has been identified and eliminated. <div>&nbsp;</div> Referring to the other Inception activities described on page 64, please explain how "Synthesizing a candidate architecture, evaluating trade-offs in design, and assessing make/buy/re-use decisions so that cost, schedule, and resources can be estimated" and "Exhibiting and perhaps demonstrating at least one candidate architecture against some of the primary scenarios", can be accomplished during Inception without producing something that executes. Executable models, prototypes, and code are all reasonable activities during Inception. I would be skeptical of any project that has nothing executable to demonstrate at the end-of--Inception review. <div>&nbsp;</div> Not doing the right thing because it might give customers a false impression of progress is ridiculous. You are responsible for educating your customer to understand the development process and properly interpret its activities and milestones. <div>&nbsp;</div> The fact that Mr. Ambler has written many books on RUP doesn't alter the fact that he has incorrectly characterized RUP in his posts here.

18 QA1-Skip commented Permalink

Scott, what is the cost of employing multiple development processes? <div>&nbsp;</div> We know that as the number of hardware platforms (or vendors), development languages or component platforms increase we see an exponential growth in the cost to maintain those systems. Today I was listening to a recorded webinar wherein the presenter said that the 'methodology' must be scalable and included maintenance projects among the categories for scaling... recalled your Agility at Scale presentation and wound up here at your blog. RMC/RUP suggested the Environment discipline craft a custom lifecycle for each project. We know that Bittner and Spence's MISDP book suggests differing Unified Process phase patterns (based on risk), and we know that many (most?) teams adopting Agile values and agile practices find a mixture of practices from XP/Scrum/Atern/UP works better 'for them' than adopting a 'strictly agile' (pun intended) fixed set from a single school. <div>&nbsp;</div> DAD assumes a full lifetime (not just development but also O&amp;M) perspective. What if we abandon that IT-centric assumption and focus on one short-term business objective which creates a project (or set -- in series and parallel-- of projects)? [Imagine a website built solely to support an election campaign -- ElectAmbler2011.org -- or to publicize a film series release.] What costs/risks incur from choosing to organize to (generally) use UP for greenfield development, Eclipse Way for enhancements, and conveyor-belt-like Scrum for feature enhancements while mini-waterfalls resolve Help Desk defect tickets or ruleset changes? Is there any cost incurred through a methodology buffet at the process (not just practice) level? And if so, does that imply a similar cost to providing flexibility at the practice level? <div>&nbsp;</div> Other ways to phrase this might be: "Why scale Scrum when we could instead choose to apply it only with small, collocated teams doing short projects?" "Why tailor RUP when we could choose only to apply it on large, complex projects?" <div>&nbsp;</div>

19 chabalgoity commented Permalink

I have defined a very similar process to some clients. (I do consulting on development processes) <br /> The difference is that I divided the Inception in two parts: <br /> the first part is not iterative and ends with a product definition at a baseline level, it is not detailed, but enables planning (could be viewed as the backlog) <br /> the second part is a short iteration to elaborate a project plan (not detailed) expressed thru a plan of releases each one having its construction and transition phases <br /> I think the DAD method is great ... its quite a lean development process ...

20 ScottAmbler commented Permalink

@DH <br /> Perhaps the team should have predicted the change in business environment, but it didn't. The change was the sub-prime mortgage meltdown in the US, something that a lot of very smart people failed to predict. I highly suspect that the failure would have been more "epic" had the team chosen to proceed with deploying into production. <div>&nbsp;</div> Also, it sounds like you're interpreting the Inception phase to be much heavier than either Mark nor I would. That's your decision, but you shouldn't assume that it's "official RUP". <div>&nbsp;</div> <div>&nbsp;</div> @QA1-Skip <br /> I likely wouldn't categorize maintenance as a scaling factor but would consider it a project/team type, something I don't address in the Agile Scaling Model (ASM). <div>&nbsp;</div> You need to look at both the cost and value of employing multiple processes, or perhaps multiple versions of the same process. So, what's the impact of not supporting a flexible approach to process? <div>&nbsp;</div> DAD assumes a delivery lifecycle, not a full lifecycle. A full lifecycle would include pre-inception work (such as project selection), a production phase (full support for operations and support activities, not just reporting defects and enhancement requests), a retirement phase (see http://www.enterpriseunifiedprocess.com/essays/retirementPhase.html ), and arguably support for the various enterprise disciplines (see http://www.enterpriseunifiedprocess.com/essays/enterpriseManagement.html). So, it's more than Scrum but less than say something like EUP. <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div>

21 DHBernstein commented Permalink

re " I highly suspect that the failure would have been more "epic" had the team chosen to proceed with deploying into production." <div>&nbsp;</div> Nowhere did I suggest that the team should have proceeded to production. I suggested that they should have been aware of the potential for change in their business environment. The sub-prime mortgage meltdown did not occur overnight; there were plenty of warnings beforehand. The fact that others disregarded these warnings does not diminish the team's responsibility for having done so. <div>&nbsp;</div> Re "you're interpreting the Inception phase to be much heavier than either Mark nor I would", I cited specific guidance regarding Inception's objectives from "The Rational Unified Process, an Introduction" which you've failed to address, resorting to hand-waving once again. My sense is that you are significantly weakening RUP, to the detriment of those who follow your guidance. <div>&nbsp;</div> My view of RUP is not "interpretation"; I lead Rational's Product Group from 1981 to 2003, when the principles underlying RUP were identified and ultimately assembled to form a process framework.

22 ScottAmbler commented Permalink

DH, you appear to be quoting from the first edition of RUP: An Introduction, published in 1999. May I be so bold as to suggest that perhaps we've learned something about IT risks since then? Anyway, nowhere in the book do I see a statement indicating that "One cannot claim to have identified a system's critical use cases until all significant requirements risk has been identified and eliminated" as you indicate, although please correct me if I'm wrong. Otherwise, then you are in fact sharing your interpretation with us. When you stop and think about it for a moment, although you might be able to claim that you should identify all risks (or at least do your best to do so) that you're very likely not going to eliminate them all -- an important concept in risk management is that some risks you choose to accept (which you may identify contingency strategies for), some you choose to reduce the impact of (but not eliminate), and some you choose to eliminate. <div>&nbsp;</div> Regardless, this blog posting is about the DAD life cycle, not about the RUP. So, you've managed to take us on a marginally interesting tangent which is clearly out of scope. If this is a topic which you want to discuss, may I suggest that you bring it up on the RMC/RUP/... forum at http://www.ibm.com/developerworks/forums/forum.jspa?forumID=335 and see if anyone else is interested?

23 DHBernstein commented Permalink

Yes, we've learned more about managing risk since 1999, but none of what we've learned would lead anyone to reduce the intensity of effort aimed at identifying and resolving risk early. <div>&nbsp;</div> The statements in my earlier comment taken from "RUP: An Introduction" are quoted. "One cannot claim to have identified a system's critical use cases until all significant requirements risk has been identified and eliminated" was not quoted in that comment; it's obvious that one cannot reliably identify primary scenarios of behavior that will drive the system's functionality and will shape the major design tradeoffs if significant risk remains in the requirements. <div>&nbsp;</div> Establishing a contingency plan is in fact a valid way to resolve a risk. Allowing a significant risk to remain unaddressed with no contingency plan is gambling, not engineering. <div>&nbsp;</div> This thread began with the observation that the DAD lifecycle pays no attention to identifying and resolving risk. The fact that you consider this of "marginal interest" confirms your abandonment of a pillar of modern software engineering: identify and attack risk early.

24 ScottAmbler commented Permalink

Dave. as you can clearly see in the DAD lifecycle diagram milestones are clearly depicted in straightforward, easy-to-understand language. Milestones are typically considered to be part of the overall risk strategy of a process, and it's one of many aspects of risk management in DAD. The Introduction to Disciplined Agile Delivery workshop offering, see http://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&amp;courseCode=RP251 , where we go into a bit more detail about DAD than I have gone into in this blog posting.

25 DHBernstein commented Permalink

Risk identification and mitigation is either a primary process driver, or it's not. Clearly in DAD, i'ts not.

Add a Comment Add a Comment