Introduction 

The Rational Unified Process (RUP) has become a defacto standard for many organizations as they look to improve their software development processes. Unfortunately, transitioning to RUP is an arduous and risky process as teams struggle with adjusting to an iterative style of development. As a witness to many process improvement efforts utilizing RUP, I've found most are little more than reinventions of an organization's existing practices. The result is a pseudo-iterative style of development that favors excessive documentation manifest as RUP artifacts, a predictive and plan-driven approach providing no clear barometer to gauge success, and a tendency to revert to traditionally flawed practices as teams succumb to the pressures of project deadlines. Certainly, RUP should not be blamed for the failure, but often times that's the case, casting a dark shadow on iterative development and making teams ever more leary to consider agile development.

RUP's Beauty 

I must admit that RUP is a beautiful piece of work. Use Case Driven. Architecture Centric. Iterative and Incremental. To the unsuspecting development team, it offers the wonderful promise of traceability. Develop a Use Case Specification. Realize each use case scenario with sequence diagrams through analysis and design. Analyze sequence diagrams for common flows (reuse). Create a view of participating classes for each use case. Allocate classes to components. Architectural analysis and design. And so on. Traceability throughout the development lifecycle. There are even tools available that support the process.

Yet in all its glorious wonder, it is RUP's ceremonial beauty that is also it's downfall. We can unneccessarily argue that it's not an inherent flaw of RUP, but more so due to manifestations of RUP. Teams attempt to stabilize architecture early. They tend to avoid construction until requirements are stable. They create iteration plans but do not deliver after each iteration. But a process with infinite variability and implementation baggage is destined to fail.

Herein lies the problems with many manifestations of RUP.

• Iterations don't deliver. The purpose of iterative and incremental development is to deliver functional software at the end of each iteration, where each iteration results in incremental growth of the system. All too often, teams fail to achieve this goal, or make adjustements when they don't. Instead, many RUP iterations resemble nothing more than traditional waterfall phases broken down into smaller timeboxes. The result is multiple requirements iterations, following by multiple analysis and design iterations, followed by multiple implementation iterations, etc.
• Traceability cannot be achieved. Many folks are quite enamored with traceability. Changes to requirements can be traced through the analysis and design model into the code through the components and onto the executable nodes. But traceability is fundamentally flawed due to syncrhonization issues across artifacts. Teams do not possess the discipline necessary to maintain consistency across all artifacts, making the source code the only true artifact representing the current state of the system.
• Emphasizing process improvement. The complexity and infinite variability of RUP make it a methodologists process, not a developer's process. Passing a CMMI appraisal may be important, but delivering quality software is the ultimate goal. Achieving one does not guarantee the other.
• Artifact centric. RUP teams utilize Use Cases and Use Case Specifications to gather and elicit requirements and detailed class and sequence diagrams that capture the vision for architecture and design. They create software development plans, test plans, and deployments plans. Probably many others. But in many cases, reviewing how a team works before and after RUP will show that little else has changed other than the artifacts produced.
• Addressing the wrong problem. In many cases, we hope that RUP will result in more stable requirements and accurate estimates. But it cannot solve problems inherent to software development. Instead of emphasizing process to stabilize requirements, process must emphasize managing change. Instead of improving predictive estimating, process must emphasize measuring based on experience and trends. Neither of these are possible if we aren't delivering iteratively.

Software Matters

If you've read any of my blogs or articles, you'll know I stand firm on a few key points.

• Process doesn't matter, practices do. I don't care to debate the merits of process, be it RUP, Scrum, or any other. I find value in the numerous practices embedded within each, but do not feel that adopting any process verbatim is the right solution for any team.
• agile is always good. Agility is defined by your teams ability to deliver functional software. Unless I'm missing something, the goal of any software development initiative is to deliver software.
• The source code is the only artifact that matters. Systems are never judged based on the beauty of the architecture diagram or the completeness of the requirements specification. These only provide a false sense of progress and security. Systems are judged based on whether the software delivered meets the user's needs.
• Increased agility requires more than practice or process. It requires tools, infrastructure, and a codebase that allows the team to respond to change. Yes...the team. That's pretty important too.
• Iterative ain't always agile. See first bullet, and recognize that if you are forcing people to conform to process over embracing process evolution, you'll find it difficult to realize high degrees of agility.

A Better RUP

RUP and agility are not mutually exclusive. RUP has the potential to increase agility by improving a team's ability to deliver software iterative and incrementally. To do so however requires teams to avoid the common problems when adopting RUP, and focus on that which is truly important - software delivery. Using RUP as a process framework, while complementing it with agile practices such as test driven development, continuous integration, and a strategy for tracking running tested features will yield higher degrees of success. Teams will generate the constant feedback, increase the collaboration, and develop the engaging relationship with business stakeholders that are important to any successful software development effort. Adopting practices to address the pain points on a project will help avoid the problem caused by sudden and radical shifts in development philosophy. Considering the dynamics and strengths of the team throughout the process improvement initiative is imperative. Eliminating waste created by artifacts that don't directly contribute to creating high quality source code will speed software delivery.

Improving a team's development process is good, so long as the folks pushing the process recognize that the goal of the process improvement effort must be delivering quality software over implementing ceremonial processes. RUP is one way to begin. As your team or organization works to improve process, don't be constrained to only RUP. Consider alternatives. The first step in improving your ability to deliver software is recognizing that a problem exists. Begin by understanding the problem. Are you having software quality issues? Are development efforts simply taking too long? Constantly exceeding your budget? Aren't able to meet business objectives? Constrained by resources? Something else? Or everything? Quite simply, you must recognize your pain, identify it's cause, and eliminate it. Then...do it again.

Comments (0)

Write comment

Show/hide comment form