RUP: A more comprehensive analysis

Today I attended a meeting where IBM/Rational got to extol their glorious Unified Process (RUP). RUP has a lot of good sides, and I think a lot of the high-level ideas are very good. Phases, workflows, artifacts, and roles all make sense. The concepts can be used to understand any process, even “non-processes” like code-and-hack. The central question then is whether the components of RUP individually are the right ones for a given project and whether their composition is appropriate.

IBM repeatedly highlighted the configurability of RUP. This configurability is an answer to many of the objections in this memo. However, at some point in time one must ask oneself whether it makes any sense to call what one is doing RUP. The speaker from IBM asserted that he had been doing RUP-for-one as well as RUP for as small teams as 3. I felt he was stretching RUP meaninglessly far. With his interpretation of RUP, I could merely assert “I am doing RUP” and carry on without changing the way I work!

Anyho: to the details. I think RUP gets the following core parts wrong:

• Putting design in the analysis workflow, and not the implementation workflow. My best experience in reducing risk and churn in development is to consider design as an activity performed by programmers as needed, not by a separate individual. Even though the two roles in RUP can be held by the same person, the fact that they belong to different disciplines make me believe that this is only intended for very small teams. The number of artifacts exchanged between these two roles support that position.
• Some of the core best practices are not. Specifically, Model Visually is a good technique for some people under a set of situations, but different people work differently. The important practice is to communicate well, and modelling visually might help you. I have not grasped the exactly meaning of “use component architectures”, but it strikes me as either obvious (“don’t write everything in one big main method”), or not necessarily a best practice (always use stuff like EJBs, buy as many components as you can). I have no problems with the other best practices.
• The value-chain is push-oriented (artifacts drive the activities through the process), instead of pull-oriented (customer need drives the software development which pulls from the requirements process etc). See “Lean Software Development” for details on pull-driven value-chains.
• The default templates and activity descriptions are overly detailed. The template for the project vision prints to 11 pages without filling out anything, contains 11 major sections (30 subsections), and suggests “capabilities are abstracted to a high enough level so 25-99 features result” (that doesn’t sound very high level to me!). The activity description for implementing one component has 7 steps, each of which has several substeps. When you look at the actual substeps they are inane to any moderately skilled developer, and probably dangerous for a lone unskilled developer.
• The focus on one external release per project eliminates some very beneficial properties of iterative development. Consultants in a fixed price project can use incremental releases and change request to extend the contract into a de-facto lower risk time-and-materials contract. Projects delivering incremental value (especially by deploying on the web), can recoup their investments sooner, lowering risks and increasing benefit by interest on the return. Both types of projects can use a ROI-analysis to keep the project constructing and releasing as long as it is judged to be beneficial. This is conscious, beneficial extension of the project lifetime. RUP does not seem to be well suited for this approach. [See “Lean Software Development”, “EVO”, “Extreme Programming”, or “Crystal” [1], or even usability techniques like “Usability Testing” for methodologies that has releasing as core best practices]

Especially the two last issue could be solved by use of development cases. But I fear that the modifications done in to achieve this would be so great that they invalidated the benefit of using RUP in the first place. You really would be using RUP in a way it was not designed to be used. The benefits of RUP diminish with modifications. As you no longer receive the full benefit of the detailed descriptions in RUP, you would not be able to make as much use of templates and artifact guidelines. As you deviated further from the straight-and-narrow path you would lose the advantage of having a large number of consultants with RUP knowledge available in the markedplace.

A Defined Process?: I want to explore the issue of the level of detail and the artifact focus a bit further. The basic schism in management between trusting your workers to do their best; and managing them to make sure they aren’t “slacking of” is still alive and well [Dr Randall Jensen, CrossTalk 1997, section “Motivation”]. Sadly, RUP seems to fall down squarely on the side of “Theory X” detail-managing your workers. Personally, I believe that if you can’t trust your workers to look out for your interests, you have already lost. No wonderful big-brother process can give you sufficient control over people who are not playing on the same team. Likewise, if your workers are so unskilled that they don’t know that in order to “Implement Operations”, they have to “Choose an algorithm” (except when you don’t, which RUP doesn’t talk about!), you don’t have much hope of succeeding with even the best possible process.

Even when you manage the activities using development cases, you end up with a fundamental problem: People differ. The right way to work for one person is not necessarily the right way for another person to work. The result is what Alistair Cockburn calls a “low-tolerance” methodology ([1] note: does not refer to RUP in this regard). A low-tolerance methodology may work excellent for the project that designed it, but is harder for a whole organization to use adopt and use efficiently.

Any successful project requires at least a significant portion of the team to be motivated and skilled. RUP defines in detail all the activities, seemingly hoping this fact will go away. I don’t think it will. And the flip side is interesting: What do you think an overly detailed process does to motivation and efficiency of your skilled workers? This is true optimization for mediocrity.

Priorities: Now we get closer to the allure of RUP and the conflict with the more Agile methods. After hearing IBM talk, I realized that RUP’s priority is on risk-reduction over efficiency. This highlights a conflict of interests in development organisations. The organization as a whole may be interested in all projects succeeding inefficiently rather than some projects succeeding efficiently and some failing. But the workers on each individual project are probably more interested in efficiency than in risk-reduction. Projects staffed with strong members will feel held back by inefficiencies of RUP-as-delivered with a complex set of artifacts, detailed templates and guidelines for each, and inane activity descriptions. This is just one source of inefficiency in RUP (under-utilization of workers due to overspecialization, excessive movement of information, and a tendency to promote rigid artifacts are others). The inefficiency will of course hinder adoption as well. This is the basic conflict of interests between the executive management and the project management.

A few interesting points arise:

• Is the focus that RUP has on risk-reduction across projects really working better than the alternatives? I don’t know the answer to this one, but my gut feeling is no. It gives an illusion of lower risk, but thinking back to dusty copies of RUP on bookshelfs, I don’t know if it actually achieves it.
• Are there other ways of dealing with the conflict of interest between executive management (lower risk across projects) and project management (improve efficiency in your project)? At least two strategies seem obvious: 1. Never staff a project with only unskilled people. 2. Kill projects that aren’t delivering early. These strategies are more sound than providing detailed activity descriptions, and RUP does in fact provide go/no-go milestones for when projects can be killed.

As a side note: For risk management WikiWiki (http://www.c2.com/cgi/wiki?RiskManagement) beats the RUP “Activity: Identify and Assess Risks”. In general: Any kind of activity that requires a skill is better explained outside RUP, and a skilled practitioner should know some of these sources.

Resource Availability: One of the unique selling points of RUP is that there are numerous organizations available that will provide consultancy services in RUP. Most alternative methods can only boast a handful consultants, and usually spread over many organizations. The notable exception is eXtreme Programming which is at least supported by Object Mentor and ThoughtWorks. Sadly, this isn’t too much comfort in Norway. I have yet to find consultant houses selling services with Crystal, eXtreme Programming, or other Agile methods in Norway. There are a few small providers or side-shows in medium sized ones, but nothing like CGEY. I clearly see that this is a problem, but it might not be as large as is often assumed.

Exactly what is a “RUP consulant”, anyway? I am going by conjecture here, but I got the impression today that RUP consultants provide services both with adapting RUP to organizations and with individual activities. The most commonly asked for activity help seems to be system analysis and requirements engineering.

Now: Even if you’re not using RUP, a RUP requirements engineering consultant can help you out. This is obviously not a RUP-specific benefit.

Lastly, for other methodologies, world-class consultants are more available than you might fear, and costs less than an army of CGEY process engineers. Really competent consultants are probably almost as hard to get with RUP. As my boss pointed out, even IBM had to fly in a specialist from Sweden for our meeting in the capitol of Norway.

The second aspect of resource availability is the fact that a being widely adopted. If you pick up J Random Developer from the street, chances are better that he knows RUP than that he knows you home-grown process. However: My experience is that J Random Developer is even more likely to know about eXtreme Programming.

Good Things: I want to wrap up with a few things RUP brings to the table that I would like I to any projects:

• The vocabulary used to talk about process
• The concept of phases with go/no-go milestones. However, I would like to release several times during construction and continue this phase until ROI-analysis showed it to be worth to transition the product into hibernation.
• Developing Iteratively. However, releasing iteratively and timeboxing iterations seems an obvious improvement. RUP uses iterations to reduce risks relative to sequential processes, but fails to fully utilize iterations for efficiency.
• The concept of using Artifacts as gateways from a phase to next. The set of major artifacts in RUP is almost perfect. (Just make Design Model a non-major artifact, and have more flows into Risk List and I’m with you)
• The concept of Workers producing Artifacts through Activities. (But not necessarily the set of roles and artifacts RUP suggests)
• The concept of different disciplines with different focus through the project. (But I’d like Realisation, that is Design, Implementation, Test and Deployment rolled closer together)

Conclusion: RUP brings an impressive amount of information together. As an encyclopedia, it is unlike anything else out there. It allows for a good amount of adaption to local needs. However, some of the less adaptable parts are far from uncontroversial in the current discussions in the field. To me, the descriptions of the artifacts and activites seem controlling instead of enabling. The sheer weight of the documentation increases this feeling.

The end result is a tools and a process that seems bureaucratic, inefficient, and not very habitable. In order to obtain the benefits of RUP, it should be used purely as a knowledge base. The process description should be taken from another methology.

My recommendation would be to use Crystal as the process definition and recommend RUP as a source of information about specific artifact and activity help.

• Software Development