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.
I don’t think any process is complete by itself – it needs some additional good practices to make them complete. I still think one should stick to do one process, instead of doing ‘both’:
Either do agile and add a number of good practices (maybe from RUP or XP), or do RUP with a number of good practices. But not both.
I wouldn’t want to hire people and say we do agile and RUP – it would only be the ones that haven’t decided who find that appealing. And I think the most talented and experienced have a clear view of what they want.
And I’ve noticed a will to hide behind words like ‘Agile’, ‘Scrum’ or ‘RUP’ – it is a way of becomming unquestionable. And with both in place, one would create a whole djungle to hide in…
This is how I see it:
Doing agile in RUP is like skiing in sand. It is possible, but there is a better alternative.
Hi Sami,
thank you for commenting. But I am sorry, I do not agree with you 🙂
First, “agile” itself is not a process. Kanban is an example of an agile process. But that I think you know.
Second, my point was that, as RUP is a process framework from which you choose bits and parts, you can do RUP in a waterfallish way, and you can do RUP and be agile. So you do RUP in an agile way. You are not doing RUP and agile. That is an important difference.
I believe that the “talented and experienced”, as you call them, are not dogmatic and choose one process. I think they know several processes, process frameworks and best practices and chooses among them to develop software. The well-quoted Japanese samurai Miyamoto Musashi urges people to learn different weapons and different martial arts schools to be able to attack the opponent in the most effective way. If you read “process” where it says “martial arts schools”, “best practices” where it says “weapon” and “the system to be built” where it says “opponent”, I hope you understand.
To re-write your skiing analogy: if you are a skier, master several types of skis; carving, off-pist, twin-tip, randonnée, etc. Master several ways to ski; slalom, telemark, etc. If you stumble upon a slope with sand, choose the correct ski and the correct way of skiing to get down the slope in the best possible way.
I am working on a blog post in this “series” about RUP where I will try to explain how you do RUP and be as agile as possible. Hopefully that will clarify my point even more.
A true master will know when to use what weapon, and he will also know what weapons he is most efficient with. In an employment situation will he commit to use the weapons that the employer restrict him to use (although possible to bend…). And it is not a good thing if the favourite tools is out of the list. Or in other words: It would be a learning experience to ski in sand, and even a fun one;) But to be a skibum in the desert, and maybe not ski on snow?
I have worked in a RUP framework, while being as agile as possible. It is hard, but possible… You need to be experienced to not fall in the sequential & documentaion trap. It is very hard to remove artifacts – much easier to add. We did use XP before, and we prioritized with risk in mind, and discussed architecture before coding. Although just in time, and not to the detailed level that we did with RUP.
But I think we have different opinions: I’d like to see risks and architecture as part of a good agile process rather than doing RUP in an agile way.
Hi Sami,
this time I think we agree more, you are actually making my point 🙂 That you can do RUP and be agile. I wrote the post partly to claim exactly that, since there are many that think that you can’t do RUP and be agile. I claim that it is because they have used the tool in the wrong way.
But yes, I would also rather use an agile process with risk management and more architecture focus, than use RUP and be agile.
PS About experts and their weapons. Read “Agile Software Development – The Cooperative Game” by Alistair Cockburn, Appendix B, page 420.
A small side note:
In the original work/description of the waterfall model the author (don’t remember the name) said that the “V” should be repeated until the system was finished. I.e. a series of “V” one after the other. Sounds a bit iterative to me 😉
Yes, it does sound iterative 🙂 Would be nice if you could find a reference to it. Sounds like interesting reading.