Agile over RUP Part 4

RUP Principles

As I have said before, one of the best parts of RUP is the principles and best practices. Probably the fact that RUP has explicit principles that are clearly articulated makes it a better methodology that many of the SDLCs that I've seen put together, especially by those in the management consultant world. In fact most SDLC I have seen don't even bother having proper principles. Having a consumable set of principles means that development teams can pretty much guide work around whether they are following a principle, not whether they are following a specific detailed piece of processed material.

I have listed below the major RUP principles along with some minor alterations in order to make them more agile.

The RUP is a use case centric

RUP makes a big deal about how every single artifact in the process can be traced back to a particular use case. In RUP, use cases are a collection of scenarios grouped together according to their ability to help a specific user accomplish a specific goal. The idea of developing use cases and then hanging your design documents, plans, test, and anything else might need off of these use cases is a great idea.

Use case traceability is a complete waste of time...

Unfortunately RUP takes what is a reasonable approach and pushes it to the extremes of absurdity. RUP recommends that you follow what is known as "use case traceability". Use case traceability is the notion that you can have a database of every artifact created in your SDLC (including code) that tracks each artifact and their traceability to each use case and each subsequently developed artifact. In my experience, this is a colossal waste of time. By doing this, you are in effect trying to track a multidimensional, real-time, many to many relationship. What makes this even harder, is the only person capable of properly managing the database of artifacts is someone who has a reasonable understanding of the entire SDLC. This is most likely a very senior person on your team and he has better things to do than traceability management. More than likely, the person responsible for managing traceability is the person who drew the short straw in your project and is almost completely clueless about what he is actually managing.

But using use cases as a framework for managing a project is actually not a bad idea...

that being said, I almost always develop and maintain a use case hierarchy like the one prescribed by Alastair Cockburn. I do not always develop complete use cases, but I do use this hierarchy (usually stored in some kind of wiki) to act as an anchor to associate most of my other major SDLC elements. Of course in the agile world, there are a lot less SDLC artifacts so usually I associate individual use case nodes with things like:

• individual user stories
  

• test cases (using tools like FIT)
  

• simple models (as needed)
  

Traceability with working code is done by utilizing a revolutionary concept known as talking to the person responsible for developing or supporting the code. Relying on people seems to be something very scary in the manager world, but rather than focusing a whole bunch of work on doing complex traceability, try spending more work on making sure that there's always somebody who knows how your solution works.
The RUP Is Architecture Centric

The RUP also makes a big deal about being architecture centric. The RUP describes architecture as a filter on the various models necessary to build the system. (e.g. requirements model, design model, implementation model, deployment etc.) This filter represents a common vision of the system, it's common components, and unifying elements. The RUP spends a lot of time describing what architecture is and what it is and using terms that would probably baffle most of us, but the point is that according to RUP, architecture is something that needs to be considered throughout all aspects of developing software. While most people who follow agile probably recoil at the heavyweight definitions of architecture offered by the RUP, what is refreshing about RUP compared to most other methodologies is that RUP believes that architecture permeates all aspects of the system. Most other methods seem to put architecture "above and around" the actual implementation of the system. RUP on the other hand, believes that architecture is represented in its requirements, its design, its code, and how it's deployed. In other words architecture is more than a bunch of pretty diagrams with boxes and lines, and it doesn't cut architects who have no desire to be involved with implementation any slack.

Architecture is important, but keep it lightweight...

Where RUP tends to fail, is in the details. RUP has lots of advice on how to develop detailed use case models, detailed use case realizations and traceability matrices necessary to modeling and maintaining the "architecture" of the system.

Keeping a focus on architecture on any large scale project is important but in order for it to be maintainable it needs to be lightweight, and focused on value. What is valuable is going to change from project to project but in my experience make sure that effort is put into developing a set of architecture and coding standards, and that everyone be on the team is aware of them.

Everything else is gravy. (And gravy is not a good thing if you're trying to stay lean)
The RUP Is Iterative

In terms of principles that add value, this is a no-brainer to anybody who's trying to adopt agile. That being said, RUP does not offer very tangible advice on how long iteration should be, and how to manage what goes on in iteration. Most of the milestones, gating criteria and metrics are based around the larger scale phases.

While the RUP makes a big deal of iterating the best advice you are going to get around how to manage iterations are going to come from things like scrum or XP. Whenever anybody attempts to adopt RUP, the first thing I do is train them up on how to manage a project using iterations using approaches described by a really good text, Agile Estimating and Planning.

The RUP Is Model Driven

The RUP phases places a heavy emphasis on developing one or more diagrams/models to represent the system. When going through the RUP, one will encounter guidelines on how to develop use cases models, use case realization models, design models, deployment models, activity diagrams, etc.

In point of fact, it's probably a full-time job just to keep up with all of the UML diagrams recommended by RUP as well as the approach to using these diagrams within RUP. The biggest issue in using these models is one of maintenance. While not specifically saying so, RUP does imply that these models need to be developed, and kept up to date using reverse and forward engineering principles.

Models have A Lot Of Value, But Use Them for What They're Worth, They Aren't the Solution

Models are actually a great thing, they help us communicate, they help us understand, and they help us abstract implementation details that can take an awfully long time to learn. But models are expensive to create, and they are incredibly expensive to maintain. Models are also only so valuable if they are developed by the technical team in isolation of the business team. In order to be useful agile modeling best practices need to be used to supplement the RUP model driven approach. In short these practices consist of

• use collaborative modeling techniques (like CRC cards)
  

• don't be afraid to throwaway models
  

• focus models on interfaces between teams, complex business logic, and code that is currently being reused by multiple teams
  

• don't create a model without having an audience in mind
  

• don't create a model because your process says so
  

When Using RUP to Scale Agile Make Sure You Follow Agile Documentation Principle

Scott Ambler, has some great on how to develop documentation in an agile manner. In a nutshell, Scott suggests that you should only document when

• you are satisfying a specific project stakeholders
  

• you have a stakeholder who can help you build a table of contents and direct you on what he wants to see
  

• when there is specific business value
  

• above all, don't create a document because some piece of processed material says so.
  

So if you've actually made it to the bottom of this document, you should have a pretty good idea about how I, and you could scale agile using specific modified portions of RUP in a pragmatic fashion. Scott Amber also has some great posts on how to scale up agile with RUP
Hopefully, anybody reading this will also have a better understanding of the particular project take to implementing large-scale software development projects.