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

Comments (25)

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>

Add a Comment Add a Comment