Why RUP Failed

February 21, 2007

What went wrong with the Rational Unified Process? A lot of smart people were involved with creating it, and it seems to incorporate so much wisdom and experience. In the early 90s I was very influenced by Grady Booch‘s ideas. I believe he helped us write some of the world’s highest quality code for aircraft/spacecraft embedded systems, in Ada of course. (Ada is still the best language I have ever seen, both for determinism and readability. But that’s a topic for another day.) How could he have let me down?

At first glance the RUP seems to give us standardized, well thought out ways to handle situations that come up over and over in software projects.

But every time I hear about RUP nowadays, it’s in association with a project failure, or at least waste that people would like to eliminate. In Agile circles, RUP advocates constantly take on the role of apologists. “RUP is actually incremental and iterative! You just haven’t seen RUP done right! Scrum is just a highly tailored version of RUP!” Etc. It starts to sound shrill. It reminds me of my leftist teachers who kept insisting communism wasn’t actually that bad, we just haven’t seen true communism yet. Granted, communism has killed 100 million people (and counting) while (as far as I know) RUP hasn’t killed anyone except Scott Ambler.

I guess I’m a little like these people by ranting against “ScrumBut.” But even doing Scrum badly is usually an improvement over what was happening before, while doing RUP badly usually seems to make things worse.

Here’s how most people tailor RUP: They start with everything — or at least everything they know since no one seems to know all of RUP. Then they remove the parts they can justify removing.

When people do Scrum, they start with the simple, bare bones framework, and add things they can justify adding.

In theory, the additive and subtractive approaches should meet in the middle with the same result. But due to where we put the burden of proof, we get a cleaner result by starting with a nearly blank slate and only adding things we determine we need.

Michael James
Danube Technologies, Inc.


17 Responses to “Why RUP Failed”

  1. […] Why RUP Failed « Finding The Best People For Agile Teams (tags: agile) […]

  2. I don’t think RUP fails, but, to modify what Ken Schwaber says about Scrum, “RUP doesn’t fail, but people often fail to use RUP correctly.” That being said, I think that it is true that RUP makes it quite easy to fail… and even worse, it makes it hard to succeed…

    The first step in RUP is to tailor the process, but there is little guidance about how to do it. I think one could argue that Scrum is an tailored instance of RUP, and I have recommended to some projects that are forced to do RUP to just do Scrum and call it RUP 🙂

    But, as you say Michael, most try to use RUP ‘out of the box,’ and that tends to lead to a waterfallish project… and all the bad non-agile stuff that comes along with it.

    Personally, I like RUP for what it tells us to think about. But, I hate the way it is usually implemented.

    – Dan 😉

  3. Lonnie Says:

    so I cant even browse the links because the god awful intrusive popup beast will not allow itself to be killed

    take it off or insist it be allowed to be killed

  4. Dan, you seem to agree with my premise that nearly every attempt to do RUP makes things worse instead of better. If so, it’s hard to escape the conclusion that the RUP initiative/product failed.

    The stuff that RUP tells us to think about that matters is already in your face if you try to build complete product increments every month (i.e. do Scrum). The problem is RUP also tells us to think about stuff that turns out not to matter.


  5. Lonnie, I disabled Snap Preview (a.k.a. “the god awful intrusive popup beast”). Hope that helps.


  6. Ade Miller Says:

    I completely agree. This was my experience with RUP – I just coldn’t figure out what to remove. It felt a bit like being given a toolbox with every possible tool and asked to build a bookend. You spend far too much time figuring out which tools to use and when. Better to start with a hammer and a screwdriver.


  7. Gerson Says:

    I think people are looking from the wrong perspective.
    RUP is good to show and explain things, but is not a remedy for incompetence.
    There is no such thing as ‘wrong tool’, or like the Swedes say: ‘there is no cold weather, only wrong cloths’
    When I listen to people talking about start with RUP and remove the parts that are not necessary , I always think about a builder that try to build a house starting from a complete castle and remove things to the point he has a small and comfortable summer house.
    I agree we should start from the bottom up, in this sense, the agile (mainly Scrum) is a good approach, but I want to point if we have a group of people working and communicating properly, taking responsibilities, sharing daily, etc (what scrum advocates) , it does not matter if we use scrum, XP, RUP, Props, waterfall, etc. The project most likely will succeed. The key issue is to have a group of people working professionally and efficient.

    I do have my problems with scrum. It is not that great approach for long term projects, big projects and teams, multifunctional, interdependent, and testing is not only code verification (ex.TDD) and daily building.
    Off-shoring scrum is a pain (my experience with India development and test was painful).
    OK, you may say that scrum can handle all these issues if we adapt and expand the concept, divide the tasks in to a manageable size, have communication between the teams, document and save properly the information, etc. But then, this is implementing processes – what is well described in many other places, so steal with pride and adapt it to your needs.

    My approach is to use Scrum (as it build a solid project base) and use ideas and processes from other processes and tools (not only RUP).
    As scrum is very open, any process can be added, only make sure all the team agrees in their hearts and use it.


  8. Gerson, thanks for your response. I agree with your point that we shouldn’t limit where we look for ideas.

    I’m interested in hearing what difficulties you had using Scrum for long term projects. This where I’ve seen it really shine. The highest performing team I know personally is now working on the eleventh release of a product that started in early 2004.

    Did someone say Scrum says testing is only code verification? Scrum doesn’t prescribe any particular engineering practices. In practice I see Scrum teams do a mix of automated and manual testing. Scrum teams that adopt XP practices such as continuous integration don’t do “daily builds” though. Once a day is way too slow.

    Scrum introduces a focus on *validation*, not just verification, by requiring monthly demonstrations to stakeholders.

    Offshoring Scrum *is* a pain. The non-painful way of offshoring is to write a detailed spec and then throw it over the wall to the offshore team, ideally one with a CMM rating of 5. Then wait for them to throw the perfect product back over the wall. The great thing about this is it buys you several months to look for a new job.

    I’m looking forward to the invention of a non-painful offshoring process that also works.

    “Big projects” is an interesting term, implying ambitious goals can only be met by large organizations. To quote DrDan, are you in the business of building product, or keeping people busy?


  9. Robert Lutes Says:

    One of the issues I live with on a daily basis is that RUP was designed for, and used by software developers. You have to fit a client’s business need into an otherwise software focused model. Most of us are building business systems and the methods within RUP while great for the development community are meaning less to the accounting, marketing, and government working type end user. That used to be the job of a business analyst to do that translation from business dweb to programmer geek. The old requirements definition also used to be the testers starting point for the creation of the test plan but now the developer and tester work from the same materials through out the lifecycle there by no one can really cross check changes and deviations. RUP did not make those translations go away, contrary to popular belief. Don’t get me wrong as a documenting tool with a development shop this is a great way to go if you are only dealing with engineers or scientists but the rest of the worlds minds don’t think in the same way.

  10. Lars Says:

    Another important issue is that the decision for using RUP is often a top down management decision, while SCRUM on the other hand often is bottom up. And the main key for process adoption/implementation success is participation of the employees using the process. To often the process of implementing RUP dies when the organization is not able to make everyone pull in the same direction. SCRUM is very simple to implement and often grows from a small group to the rest of organization, thus when the management starts to listen you will probably already have several groups within working as process drivers and creating anticipation.

  11. That’s a good observation. Though lately we’re getting calls from upper management wanting to somehow impose Scrum on their teams. i.e. “Self organize, dammit!” This kind of forced “rollout” doesn’t work so well.


  12. […] Why RUP Failed « Finding The Best People For Agile Teams (tags: rup scrum) […]

  13. Zandao Says:

    I have never heard of a communist, there is/was no such person. But I’ve seen a lot of bad socialists that says they’re communists. Just like Soviet Union – a corrupt socialist government that was able to make millions of people believe they were communists – something a human being is not prepared to be.

  14. Jeff Says:

    I came for the skype applescript, but read a bit as well.

    People who blame communism for death are really ill educated on that particular topic.

    I could introduce you to just over 20 people who lived in the Soviet Union during communism & they actually miss it.

    It is only capitalist propaganda that makes you believe it was a failure & that humans are not prepared to enjoy living that way.

    Americans have been raised to be consumer oriented worker bees who don’t know how to truly enjoy life. (For the most part)

  15. Jeff Says:

    BTW the way Stalin is not totally representative of Communism (as in Hitler doenst represent all silly mustache growers.

    Though he probably killed that particular style of mustache.

  16. The flying saucer people, 911 conspiracy theorists, Holocaust deniers, America haters, and communism apologists have enough places to bloviate without cluttering up my blog.

    For now I’ll leave Jeff’s posts as an example of the human tendency to cling to failed belief systems.


  17. Yaro Yambile Says:

    As the old joke goes:
    Government Official #1 “Is this it? Have we achieved full communism?”
    Government Official #2 “Oh no, it’s gonna get a whole lot worse.”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: