Grady Booch On Rational Unified Process

Ok, I'm about to tell you everything you need to know about the RUP...all else is simply details.

First, the essence of the RUP may be expressed in its six best practices. These are not an invention, but instead are a reflection of what we've seen in working with literally tens of thousands of projects over the past 20 years, codifying what works in successful organizations and what is noticeably absent in unsuccessful ones:Is this useful....

Develop iteratively (every project has a regular rhythm, manifest as a series of continuous, regular releases of executables)
Model visually (we model so that we may better reason about the systems we are trying to build; the UML exists as the standard means of visualizing, specifying, constructing, and documenting these artifacts of a software-intensive system)
Manage requirements (everything is driven by use cases/stories which are continuously discovered, refined, and managed in the rhythm of the project, and so in turn drive unit and systems test as well as the system's architecture and therefore implementation)
Control changes (change is good insofar as it is directed by aggressively attacking the risks to success in the system)
Continuously verify quality (test continuously, using the use cases/stories as the baseline, and use these tests to measure progress and identify risks along the way)
Use component-based architectures (one grows a system's architecture through each iteration; we validate and verify the system's essential architecture early on so as to aggressively attack all technical risks and to raise the level of abstraction for the rest of the team by explicitly making manifest the design patterns/mechanisms and architectural patterns that pervade the system.

Second, there are a few implicit practices:

Develop only what is necessary
Focus on valuable results, not on how the results are achieved
Minimize the production of paperwork
Be flexible
Learn from your mistakes
Revisit your risks regularly
Establish objective, measurable criteria for your progress
Automate what is human-intensive, tedious, and error-prone
Use small, empowered teams
Have a plan

Third, there's some terminology worth noting, so that we level set the vocabulary of the process to all stakeholders:

The conduct of a project tends to follow four major phases, the end of each which represents an important business gate: inception (when the business case for the project is established and the basic boundaries of what's in and what's out of that case are drawn; at the end of inception we can say "yes, we should do this"), elaboration (gated by the establishment of the system's essential use cases and architecture, representing a direct attack that confronts the essential technical risks to the system; at the end of elaboration we can say "yes, we know we can do this"), construction (wherein the system is grown through the successive refinement of the system's architecture, along with the continuous discovery of the system's desired behavior; at the end of construction we can say "yes, the system is in a place where it may be fully deployed to its users" [it may have been incrementally deployed during construction, of course]), and finally, transition (wherein the business decision is made that aggressive investment in the system is no longer necessary, and the system enters a plateau of use and maintenance; at the end of transition we can say "this system is at end of life")
Since the RUP is about deploying systems for which software is an essential element (acknowledging that executables are the essential artifact that's produced continuously but that this labor has a business, economic, and technological context whose stakeholders contribute), there are several disciplines that engage in the development activity: business modeling, requirements, analysis and design, implementation, test, deployment, configuration and change management, project management, and environment. These disciplines represent different stakeholders, different views into the system, and different skill sets. Each discipline has its own rhythm, but all in harmony with the essential construction rhythm of the project as a whole.
In the conduct of a project, the RUP provides a common vocabulary for those things that get created during a project (artifacts), the roles/skill sets who create those things (workers) and the concurrent, interweaving workflows that those workers typically follow to manipulate those artifacts (activities).

That's all you really need to know...

Really.

-- GradyBooch on the XpMailingList

Anyhow, looking at the best practices listed here versus an AgileProcess, the only explicit difference I can see is that "Control change" is philosophically opposed to "Embrace change". Control change is based on fear; embrace change is based on courage. ScrumProcess would also claim that control change isn't possible in a software project (at least not in the sense of "defined" process control; Scrum suggests using "empirical" process control instead).

Many would say that to embrace change you need to control it. It may be a semantics issue but I don't think embracing change implies throwing a blind eye to change.

If you use the word 'child' in place of 'change', you can see where my bias lies. 'Control change' is to 'embrace change' as 'control a child' is to 'embrace a child'. Thus, in my opinion, you don't need to control a child to embrace him or her. The two parenting philosophies are in fact very different, if not diametrically opposed. I'd say the same of software process philosophies. Of course, it's just an analogy and it's just my opinion.

As to 'throwing a blind eye to change', of course I agree with you; I'm just trying to highlight the underlying philosophical differences between RUP and more-agile methods. RUP assumes change should be controlled, like it is on an assembly line. Agile methods assume change should be adapted to because they also assume that it cannot be effectively controlled, like the wind; bend with the wind instead of being broken by it.

: I think this comment misses the point. It does not say "Resist change". "Control change" refers to basic things like version control, do builds frequently to ensure the software continuous to work as change happens, defect and change tracking and doing things incrementally to adapt to changes during the project. To wit "Control Change" really refers to HOW TO "Embrace Change"