1- eXtreme Programming:

At a business level, XP is about flattening the cost-of-change curve
such that it is no more costly to add a feature later in the
development cycle than early on. Viewed from traditional
methodologies such as the waterfall methodology, this seems insane.
How can change have such little effect? The idea is that change is
embraced; it is planned for and expected. The software is
continually refactored as its being developed to keep it simple,
clean, and agile at all times. Change occurs in small incremental
steps when using XP, leaving the system in an ever production-ready
state. Feedback is rapid, with end-users ideally onsite during
development to provide immediate answers.
Testing, testing, testing:
Quality is the one inflexible variable of the four variables in a
software project: cost, time, quality, and scope. Quality is usually
one to focus on, because anything else just delays problems until
they cost more to fix. Scope is the ideal adjustable parameter, with
the others being more or less constrained externally from the
development team. Quality is obtained by testing. Unit tests are
developed before production code is even written. Continuous testing
and integration are crucial to obtain agility in adapting to change.
Keeping code simple and clean is tough as it evolves and cruft
forms, but having test suites in place gives developers the courage
to undertake massive refactorings to simplify things once again. Run
the tests successfully, make some code changes, and run the tests
again. If the tests break, you know precisely what just changed to
cause the breakage.

2- Rational Unified Process:

The Rational Unified Process (RUP) is an iterative, prescriptive,
architecture-centric process in which the code is merely one of
the "artifacts" delivered by iterations of the project: design
models and code documentation are usually other key artifacts. To
direct the design and development, the intended uses of the system,
the Use Cases, are central. These are used to provide insight into
the problem domain, and a focus for development.
The RUP divides the software process into four phases (inception,
elaboration, construction, and transition) with different tasks
(Business Modeling, Requirements, Analysis and Design,
Implementation, Test and Deployment) consuming different resources
in the different phases. There can be a number of iterations in each
phase, and even in later phases, the high-level tasks in the
process, such as requirements analysis and design still take place.
This enables, yet controls, change.
Rational provides a large and integrated suite of products to
automate the different stages of the software process, of which
their modeling tool, Rational Rose and configuration management
tool, ClearCase are probably the most well-known.
Where the RUP seems to be weak is that, it delays deployment until
the tail end of development. For large web or enterprise
applications, deployment is one of the hard and risky parts of the
process, so should be emphasized earlier and fed into the basic
architecture [Loughran02-1] as well as into every iteration. This
does not mean that RUP is unnecessary for such projects, merely
insufficient; there is a proposal to explicitly include production
as a new phase for the RUP and operations and infrastructure
management as new tasks in a project [Ambler01].