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

Comments (25)

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