Agile and Rational Unified Process (RUP)?

Scott Amber in defence of RUP.

The point is that these problems are self-inflicted, that these organizations could just as easily have chosen to instantiate the RUP in a light and effective manner, and better yet in a truly agile manner. In practice the RUP can be as agile as you want it to be, but you need to choose to work this way. Some important observations: RUP socialized many of the concepts that Agile was built on.

Some important observations:
  1. RUP socialized many of the concepts that Agile was built on. Although the concept of iterative development was around long before RUP, for many organizations RUP made the concept palatable through its mature approach (particularly when compared to some of the RAD/Spiral strategies at the time). In many organizations RUP also socialized testing throughout the entire lifecycle, delivery of working software each iteration, and collaborating closely with stakeholders throughout the project (to name but a few). These ideas seem straight forward today, and they’ve been taken to even greater extremes in some cases , but back in the mid-90s this was pretty heady stuff for the vast majority of practitioners within the IT community.
  2. RUP has adopted many of the “new” agile techniques. RUP is a process framework containing a wealth of IT practices, including both agile and traditional practices (and a lot in between). RUP continues to evolve, capturing industry best practices from many sources. So naturally RUP has adopted many agile concepts such as test-driven development (TDD), continuous integration, embracing change, and others. Check it out and see for yourself.
  3. RUP is as agile, or non-agile, as you want to make it. I’ve said it before and I’ll say it again — the RUP is a process framework from which you instantiate processes. You’ve got complete control over how agile the RUP is.
  4. RUP contains many of critical techniques for scaling agile. In a previous blog posting I looked at the issues around scaling, not only is team size an issue but so is geographical distribution, regulatory compliance, application complexity, legacy systems/policies, governance, and organizational distribution.