RUP isn’t agile but some of its principles are worthwhile

Why RUP isn’t Agile?

I work with a number of people who come from a RUP background and who claim that RUP is Agile because RUP calls for iterative development. While a cursory reading of RUP literature may show that the RUP framework doesn’t really mandate anything — it is a framework not a process — and leaves things up to the team and organization, it’s spirit couldn’t be further from Agile. I just have a hard time reconciling some of  the ideas behind RUP to Agile values and principles

Consider the following:

RUP is predictive and calls for component based architecture, use of use cases for specifying requirements, and UML as the language for specifying design.

While RUP proponents may claim that official RUP literature doesn’t really mandate that use cases are the only way to specifying requirements, every explanation, presentation, or book always depicts RUP as use case driven. They also contain diagrams that mention the percentage of the use case model that should be completed by the end of each phase of the RUP. Moreover, the official documentation cleary states that “The Rational Unified Process is a use-case-driven approach” and the entire set of documentation refers to use cases and the use case model — use cases play a major role in several of the critical process workflows.

RUP calls for iterative development within a waterfall process. It does not aim for frequent releases at the end of each iteration; releases are done at the end of a transition phase after cycling through the Inception, Elaboration, Construction, and Transition phases, each of which is composed of multiple iterations. It basis reeks of Waterfall development — gather requirements, design, implement, and transition to production.

RUP encourages granular division of labor where specialists hand off documents to one another at specific points in the process. Their roles depend on the quality of documentation to guide their work. Agile teams look for generalizing specialists and makes no distinction between roles. All team members are accountable for the product! RUP roles are accountable only for their portion of the process.

Agile teams are assigned to one project at a time and everyone is busy during an iteration. During RUP phases, what is one group of roles doing in the other phases? Are people multitasking and working on different projects at the same time?

XP requires TDD and Scrum encourages adherance to good engineering practices like those followed by XP; RUP doesn’t and is instead a mini waterfall.

Agile methods call for aggressive refactoring and the discovery of a final design; RUP calls for an initial candidate architecture, UML to elaborate use cases and other design artifacts that become the basis for construction.

RUP prioritizes based on risk; agile on business value, which is a function of scope, quality, cost, and time. Too often projects in companies that adopt RUP seem to have an architecture/IT focus; business value is rarely if ever mentioned. This is also evident from how the use cases are written; they have an IT slant to them and are rarely written from a user’s perspective.

RUP is silent on the active removal of roadblocks; agile is chiefly concerned with identifying and removing roadblocks whether created by the team, management, or the organization.

Companies that adopt RUP often have a number of related heavy-weight Rational/IBM tools. It seems like a discussion of tools is often a major topic for RUP speakers these days. Agile teams on the other hand like to travel light and use the simplest tools possible — whiteboards, sticky notes, index cards, agile models, etc.

So can we learn anything from RUP?

This is not to say that we cannot learn anything from RUP. An initial focus on architecture and risk identification and mitigation is a good strategy especially when the project involves a degree of novelty (new technologies, new domains) or when the team is not composed of Journeymen or higher (“The Seven Stages of Expertise in Software Engineering” by Meilir Page-Jones ). Far too often, I have seen Agile teams struggle with the implemented architecture iteration-after-iteration; a short initial focus on specifying a candidate architecture would have been beneficial in most situations. Most probably, if the team was composed of superstars I wouldn’t have seen this problem. But there aren’t too many teams of that nature that I have come across.

Use cases though maligned by some, and bastardized by others, have their place. There has been a recent trend by Agile teams and Product Owners to write smaller-and-smaller stories to fit into shorter-and-shorter iterations. The result has been over-fragmentation and a loss of unity and cohesion; it becomes difficult to quickly see how the pieces fit together and how the process flows together. Use cases (if written properly) help us see the forest for the trees (see Alistair Cockburn’s writings and Craig Larman’s POS example in “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development” for good examples and principles to follow).

Considering risk and developing strategies for tackling them early is a smart idea. Spiking and implementing risky portions of the infrastructure and architure helps drive out risk early and prevents surprises later.

Modeling is a useful exercise if it doesn’t become an end to itself. Instead of UML, team members can gain much more insight by drawing simple, informal models on whiteboards (see Scott Ambler’s Agile Modeling Web site at http://www.agilemodeling.com/ for creating effective and light-weight models).