Having mentioned the acronym “RUP” at Crisp a couple of times, I am starting to get a better understanding of how Harry Potter felt when he mentioned the name “Voldemort” (if you don’t know who Harry Potter is, just borrow the book from the nearest 13-year old and read it). What is it about RUP that has made agilistas scream in terror whenever mentioned? Is RUP a hideous beast that no one can work with, or is it actually a trainable pet that can be useful when treated right?
My view of the history (I got in to the software business in the beginning of the 1990’s), is that during the 80’s, it was pretty much waterfall type of processes that dominated the software industry. Then, in the beginning of the 90’s, RAD (Rapid Application Development) came along, as a reaction to the waterfall process. But RAD had too little process which also made it difficult to create sustainable software.
Then in the mid 90’s, RUP was created by combining the thoughts of Ivar Jacobson, James Rumbaugh and Grady Booch (and Phillipe Kruchten should be mentioned as well). RUP tried to address the shortcomings of both RAD and waterfall by creating an iterative process (to allow feedback) that was focusing on eliminating risks and biased towards architecture (both more or less missing in RAD).
But RUP was not that easy to understand. It was packaged as a process framework from which you should choose your bits and pieces to use. The choosing part was missed by many who instead tried to implement more or less everything mentioned in the RUP process framework, which of course resulted in even more focus on documentation than software. This was very much not the intention of the creators. But it led to common misconceptions such as;
- that RUP was nothing but Waterfall dressed up to look like an iterative process.
- that RUP was focused on documentation.
- that RUP said that you need to document the whole system in UML.
- and so on…
As many teams and companies failed with RUP, they moved on to agile instead.
Just to quickly compare the core values of RUP with agile; RUP’s principles (from “The Rational Unified Process Made Easy – A practitioner’s guide to the RUP”, by Kroll&Kruchten, 2003) are;
- Attack major risks or they will attack you
- Ensure that you deliver value to your customer
- Stay focused on executable software
- Accommodate change
- Baseline an architecture early on
- Build your system with components
- Work together as one team
- Make quality a way of life, not an afterthought
Not all that different from Agile, right? Hey, even Martin Fowler said in 2005 that you can use RUP as an agile process (search for RUP in the text).
The major differences being that Agile is not risk driven, it is business driven and that Agile does not advocate baselining an architecture, but rather evolve it.
So what is my point?
I believe in many things, for instance in agile, it is my preferred way of working and I recommend it and teach it to clients to become their preferred way of working. I believe that RUP has shortcomings when compared to agile (which I will address in coming blog posts). But I also believe that RUP has some fair points that should not be forgotten and that Agile is not a silver bullet. I believe that a crappy team will fail regardless of process, as well as a good team will succeed more or less regardless of process. There is not one tool (insert your favourite agile process here) that solves all problems.
RUP is not easy to really understand as it is very prescriptive and tries to cover most of the areas that you can encounter during software development. This is done by describing a multitude of roles, artifacts and activities. You must understand that the key to taming the hideous beast is to remove the parts you do not need (which in RUP termonology is called creating a development case), and thus adapting it to the style of software development your team/department/company is practicing.
If you master the trick just described, I believe that you can use RUP and be agile.
So yes, RUP is a trainable pet that you can use to create great software!
In coming blog posts, I will try to explain how to be more agile with RUP, maybe as a step towards moving to agile altogether. I will also try to explain common mistakes with RUP and how you can fix them.
I encourage you to comment to this blog post if you have any questions concerning RUP and/or agile and how to combine them, or to email me, and I will answer to the best of my knowledge.