XP Vs. RUP

[Michael D. Brown]

I am curious what the general membership thinks about XP vs RUP. Is there a stigma associated with either for a consultancy? I do not currently adhere to a process formally. I do provide business analysis, architecture, and development but not within the contexts of a formal process.
Which process would you recommend I learn? If I were to hire employees in the future, for which process am I more likely to find experienced candidates?
Thank you for your time. Keep up the great work.

[Lasse Koskela]

Is there a stigma associated with either for a consultancy?

There definitely are stigmas. XP is seen by big consultancies as ... something that doesn't make big dollars. So they're not too interested in general. RUP on the other hand, has the stigma of a slow giant. RUP is not a slow giant as such, but most implementations of it are. However, because everyone has been doing RUP for years already and because the typical RUP implementation includes a lot of excess work, consultancies like it--more hours to charge on the client and the (false) impression of assured quality.

Which process would you recommend I learn?

I'd suggest investing some money on books such as Larman's Agile and Iterative Development or Boehm's Balancing Agility and Discipline. They both discuss the subject in a pragmatic, sensible way without falling for hype or prejudice.
Once you've developed that tough skin for hype attacks, then it's good to start reading up on specific process models or frameworks, for example, RUP and XP. Keep in mind that there's always a "sweet spot" for a software process and you must customize in order to achieve the optimal process for your particular organization and your particular project.

If I were to hire employees in the future, for which process am I more likely to find experienced candidates?

Probably RUP. Then again, XP is gaining a lot of mindshare in universities these days so things might change. You also need to remember that RUP is a process framework, not a process instance, and candidates who have participated the customization are much more rare than those who have only used whatever it was that came out of that customization.
[ November 22, 2003: Message edited by: Lasse Koskela ]

[Lasse Koskela]

You might also be interested in the following resources:
RUP vs XP
RUP and XP
Agile Practices and RUP
Extreme Unified Process
A Comparison of RUP and XP
The relationship between XP and RUP has also been discussed earlier in this forum:
https://coderanch.com/t/130121/Agile/RUP-vs-Agile-process
https://coderanch.com/t/130178/Agile/difference-between-UP-RUP-XP
https://coderanch.com/t/130245/Agile/Difference-between-XP-RUP

[Lasse Koskela]

If I were to hire employees in the future, for which process am I more likely to find experienced candidates?

One more thing to add regarding this question... I really think you should not be asking this question. Hiring a candidate with 5 years of experience in RUP projects might do you harm if your projects don't happen to be similar to those the candidate participated during the 5 years. I've seen plenty of developers/architects/project managers who have been doing RUP for a long time, and to be honest, many have lost the pragmatic way of thinking and are just adding practices/ceremony for the purpose of having more bragging rights or because "the book says so" (even though it doesn't).
You should evaluate the candidate's ability to adapt. Not her ability to follow the exact same process for years and years.

[Michael D. Brown]

I must say thank you to all for your prompt replies. I wasn't expect so much so soon.
You have all given me a great launchpad for selecting a process. Thank you very much.
Michael
p.s. I realize that choosing an employee based on "five years of RUP" is about as backwards as looking over a qualified developer because he used Websphere instead of Weblogic in most of his projects. What I meant is how likely is someone going to have at least a basic familiarity with the process.

[Lasse Koskela]

What I meant is how likely is someone going to have at least a basic familiarity with the process.

Ok. I think the answer is still RUP. I'm basing the answer to my observations thus far that even though most people have an incorrect idea of what both RUP or XP are, they are generally less wrong when it comes to RUP...

[Ilja Preuss]

You should also take a look at the works of Alistair Cockburn - especially his book "Agile Software Development". His point of view is that every project actually needs its own custom tailored process (which then also needs to be adapted over time).

[Stan James]

Another vote for Cockburn - he's very level headed about the pros & cons of various methods and has good "street cred" from visiting and paticipating in many projects. The only Larman I read I didn't care much for, but it was for a class I didn't like either, so maybe that was the problem. I see his new stuff cited all over the place and plan to dip in again.

[Michael Van]

Here's another way of looking at this question: lightweight vs heavyweight. Both RUP and XP are touted by thier creators as a sum of a number of tools that can either all be used, or only a portion. The difference is that in XP, the tools are focused on a customer-driven model whose goal is to quickly and efficiently code what the customer wants, and no more.
RUP is part of the OOA&D mindset that focuses on the processes less than the product. In large corporations, governments, etc. this process focused approach is more likely to get attention.
Of course, if you're on the development floor, you're probably trying to focus on getting your code done, hopefully correctly. You may not be concerned with the methodology you're using until you've been programming for a few years commercially. After having to go back and comment, document, write unit tests, and miss a few deadlines, perhaps you'll start incorporating these items into your coding.
Regardless of process, the real test of a programmer's ability is the length of time they've been programming. IMHO a programmer that has been programming for less than a year or two doesn't understand the prices paid by poor documenting or testing. The process used is about as important as how fast you type. If you know that documentation, unit testing, and proper cm are good ideas, you'll do them, regardless of the framework.

[Ilja Preuss]

Originally posted by Michael Van:
Here's another way of looking at this question: lightweight vs heavyweight.

Mhh, I wouldn't say that RUP has a weight at all. Certainly most instances of RUP are rather heavyweight, but you *can* create lightweight ones, too. (You could even argue that XP - at least technically - is one.)

Both RUP and XP are touted by thier creators as a sum of a number of tools that can either all be used, or only a portion.

Well, it's true that you *can* use practices of XP in isolation, but you are rather expected to start by using them all in concert (until you gained the ability to evaluate and adopt them).

RUP is part of the OOA&D mindset that focuses on the processes less than the product. In large corporations, governments, etc. this process focused approach is more likely to get attention.

I am not sure what you are at here. Would you like to elaborate? Thanks!

[HS Thomas]

Originally posted by Ilja Preuss:

I am not sure what you are at here. Would you like to elaborate? Thanks!

I'll hazard a guess, that Michael means that government organisations prefer a more Big Design Up Front approach.
regards
[ November 26, 2003: Message edited by: HS Thomas ]

[Lasse Koskela]

I'll hazard a guess, that Michael means that government organisations prefer a more Big Design Up Front approach.

This reminds me... Whenever you encounter someone saying things like "this project is so complex/big that we must do it the waterfall way", do remind them that even the almighty DoD is preferring iterative and incremental software development these days in their standards. If you feel like namedropping some more, you can throw in a reference or two to certain air traffic control systems built in North America and how IBM's financial services department (or something like that) went iterative already back in the 70's...
It's true that most governments and other bureaucracies do prefer the BDUF approach. It's our responsibility as conscious software professionals to do our best in educating them one step at a time.

[Nate Johnson]

i will give my opinion since i have used both methods in the past...
rup requires a big design that you need to get right all up front... sure you can gather requirements and write design docs and see if the client is happy, then create a prototype, etc, etc...
that seems crazy to me, because even if you do what the client wants, spend a year or two doing it, and give it to them, they will surely change their mind or come up with some new functionality that they want you to go back and change, and it has been my experience that in this model, it can be difficult to make these changes.
so you can see that i prefer xp. you make your goals for the day, and find out if this is what the client wants... repeat day (or by the week, whatever) after day. also, pair programming is also very productive and helps the entire team learn from each other.
find out what works for you and your team and stick with it... i would recommend xp, but that's just me

[Lasse Koskela]

Originally posted by Nate Johnson:
find out what works for you and your team and stick with it...

Noooo... Find out what works for you, do it that way, and keep finding out what works even better. Status quo is never optimal for long (the same thing as with requirements).

[Ilja Preuss]

Originally posted by Nate Johnson:
rup requires a big design that you need to get right all up front... sure you can gather requirements and write design docs and see if the client is happy, then create a prototype, etc, etc...

With all due respect, but that's *not* what RUP *requires*. It might be what many RUP shops are doing or RUP consultants are propagating, but that's far from being the same. In fact, Grady Booch several times assured on the XP mailing list that it isn't what they meant when "inventing" RUP.

that seems crazy to me, because even if you do what the client wants, spend a year or two doing it, and give it to them, they will surely change their mind or come up with some new functionality that they want you to go back and change, and it has been my experience that in this model, it can be difficult to make these changes.

Full agreement!

[Nate Johnson]

Originally posted by Lasse Koskela:
Noooo... Find out what works for you, do it that way, and keep finding out what works even better. Status quo is never optimal for long (the same thing as with requirements).

yes you are quite right

[Nate Johnson]

Originally posted by Ilja Preuss:

With all due respect, but that's *not* what RUP *requires*. It might be what many RUP shops are doing or RUP consultants are propagating, but that's far from being the same. In fact, Grady Booch several times assured on the XP mailing list that it isn't what they meant when "inventing" RUP.

yes you are correct... i guess what i should have said was that is is the only way i have ever heard it described or seen it used... sadly, i guess

[Ilja Preuss]

Originally posted by Nate Johnson:

i guess what i should have said was that is is the only way i have ever heard it described or seen it used... sadly, i guess

And more sadly, that's quite common experience...

[Scott Ambler]

You can in fact choose to be quite agile with RUP, but it's a choice. For example, at http://www.agilemodeling.com/essays/agileModelingRUP.htm I describe how to tailor Agile Modeling into the RUP. Unfortunately this isn't something that a lot of RUP shops tend to do because:
1. They've made a huge investment in Rose and don't want to discover that they really only needed whiteboards and some paper for most of their modeling efforts.
2. RUP consultants who charge by the hour make a heck of a lot less when you streamline the modeling and documentation efforts.
3. Most organizations who adopt RUP seem to lean towards a command-and-control mindset. If they leaned towards agility, then more than likely they'd adopt XP or FDD instead (and hopefully tailor AM into it to improve their modeling efforts.
- Scott

[Ilja Preuss]

I think another reason probably is that it's much easier to notice that your process is missing something than that it is too heavy weight.
Also, in a culture where it is easy to get blamed for failure, you might want to just do that other thing, too, to be totally sure... :roll:

[Rick Hightower]

Learn them both. (at least learn about them).
Then cater a process based on either or both that fits your organization.
There are good ideas in UP and there are good ideas in XP. They have some things in common as well (like iterative development based on feature descriptions).
I think you could be working in RUP shop and still practice many of the XP practices like TDD and pair programming. I don't think that one approach excludes the other.
Too Extreme?
What if you could take the key principles and ideas from Extreme Programming and package them so that they could be more applicable to any type of process. As a consultant, I cannot always pick the process that the team has chosen. And, quite often there is a lot of resistance to the idea of Extreme Programming but not the ideas of Extreme Programming (read that again). Often times companies have already picked their process and best practices. Can you impact what is in place without causing massive political disruption? Extreme Programming causes much more resistance then it should. Can you seperate the idea of Extreme Programming from the ideas of Extreme Programming? Can you soften the tone of Extreme Programming so that it is not so "in your face different" than the accepted school of thought?
I think you can. According to dictionary.com a principle is "a basic truth, law, or assumption". Since Extreme Programming is based on principles for effective development, then these basic truths must apply to other methodologies and processes. Let's start by renaming this to Principles and Practices of Effective Developers. Then let's soften it to make it more palatable to people who would otherwise have a natural aversion to Extreme Programming. Since this is based on XP principles and for that matter agile programming assume all ideas are really variations of ideas presented by Kent Beck, Scott Ambler, Martin Fowler and the rest.
To begin, let's make the following assumption: The Ultimate goal in any software project is to deliver working software in a timely manner. The software should meet the customer�s needs and expectations (at least their needs).
There are many other ancillary goals to achieve this ultimate goal. In addition to many goals, there are many ways to meet those goals. To meet these goals you need to make some key decisions as follows:
"Reckless" coding vs. very disciplined
No design vs. Paralysis Analysis
When is it Paralysis Analysis?
Should all projects be treated equal?
Pace Maker Embedded Software vs. Online Catalog
Use a Lightweight methodology or heavier weight?
Ad Hoc vs. RUP or SCRUM or FDD or XP
How do you identify what is heavy weight?
Code-centric process vs. Document Centric
How much design and documentation is enough?
For example: To what level you will design the project up front. The level of detail you put into the design has a relationship to how much feedback you can get back from your customer, and how catastrophic failure would be. For example, if you are writing embedded software for a pace maker, you cannot expect a trial and error approach. The specification, design and testing will all have to be very rigid. On the other hand, an online catalog is a lot less rigid. Often customers don�t know what they want until they can work with a working version, and you expect several iterations of changes (your process should reflect this).
Notice that the most of the choices above are degrees on a continuim. This is nice since they can be adjusted according the project, management style, corporate culture, etc. How do we adjust these? Are there principles to tell us?
The decisions above are not taken lightly. They are different depending on makeup of your team, corporate culture, and type of project you are working on. It is easy to advoacte a rigid process or methodology, but this will not work. Every methodology has its strengths and weaknesses, and no methodology (unchanged) fits every combination of project, corporate culture and team.
Purists and Evangelist be damned, there is no one size process and methodology that fits every organization, corporate culture and project. However, there are principles, values and practices applicable to all projects and are key to making decisions listed above. At times (as a consultant or even an employee), you do not always have the power to change the companies software process.
Now we agree on the goals. What are the things we value the most to reach those goals. Here are the 5 main values lifted mostly from Kent Beck with one stolen from Scott Ambler:

5 values of an Effective Developer
Communication
Customer Centric, Stories (Use Cases, Feature Descriptions)
Shared Knowledge (Pair Programming), Task Estimation
Iteration Planning, Design sessions
Simplicity
Choose simplest thing that will work
Choose the simplest design, technology, algorithm, technique
Feedback
Small iterations, frequent deliveries
Pair programming/constant code review
Continuous integration, automated unit tests
Courage
Courage to refactor, estimate, throw away bad code
Automated testing breeds courage to change code
Humility
Trust, Constructive confrontation, Don�t underestimate peers
Value others skills: manager, project manager, customer, marketing
Arrogance: �Pointy hair boss�, �Dumb customers�, �Unrealistic Project manager�.
Senior vs. Junior; Cowboys okay (white hats only); Respect Individuality and Strengths of team members
Communication
:
It should be no surprise that communication should be valued. Any team larger than one needs effective communication. (Even a team that has one developer is larger than one: the customer makes two.) Let's cover some common forms of communication for an effective developer. Stories (Use Cases, Feature Descriptions, User Stories etc.): Have the customer help with the Stories. User Story become major milestones for completion; they communicate to the team the progress of the project. Customer Centric: Let the customer drive through user stories, iteration planning, feature requirements, etc. Prioritize user stories by doing the ones that provide the most business value first (customer picks). Shared Knowledge (Pair Programming, Knowledge Management): Working together is faster than working alone. Code is not reusable unless others know how to reuse it. Task Estimation: Estimate based on past performance. Be honest and task estimation gets easier as the project progresses. Iteration Planning: Refine Stories and estimate tasks for this iteration: work with the customer to do this. Stories are excellent goals for an iteration. If the story is too big, split into two or more stories. Or if the story can not be split split the story parts into two iterations. Design sessions: Design can be done during implementation if it helps you understand problem domain or during Iteration Planning if it helps plan the iteration. Design helps the team communicate ideas quickly. Design until you can proceed with code. Feedback: Feedback is very important. It is hard to judge where a project is and how much progress you are making without feedback. No feedback is like not having a compass. Small iterations, frequent deliveries: This shows that certain features of the system work, complete with unit tests that pass. Also the sooner the user (or marketing) can provide feedback, the more likely the project will stay on track.

Let it go; Don't be dogmatic
I don't see castrophic differences between Use Case Scenarios as compared to User Stories. Use Case Scenarios are much more detailed and are a bit more organized but the goal is very similar to User Stories. Both are used to break the project into milestones and are used to divide a project up into iterations (one for the Unified Process the other for Extreme Programming). From now on, I will refer to this concept as a User Story. Don't be dogmatic about Extreme Programming, RUP or any methodology. You have a better chance of improving your process gradually then you do by taking a dogmatic stance. For Example saying: "Use Cases suck. It is too complex. Let's just do User Stories" will not do much good in a RUP shop. Nothing can stop progress faster than making such a statement. Prefer gradualism. Most of principles of an Effective Developer can be flown under the radar with full support from management. Focus on gradual improvement not arguing or taking dogmatic stances. I agree that it is not as fun, but it is sure more productive.
More can be found at

http://rickhightower.blogspot.com/2003_01_01_rickhightower_archive.html

[Ilja Preuss]

Originally posted by Rick Hightower:
I don't see castrophic differences between Use Case Scenarios as compared to User Stories. Use Case Scenarios are much more detailed and are a bit more organized but the goal is very similar to User Stories. Both are used to break the project into milestones and are used to divide a project up into iterations (one for the Unified Process the other for Extreme Programming). From now on, I will refer to this concept as a User Story.

The difference might be technically small, but it *might* also be subtle and make a big difference in the outcome. So I think it *is* important to be aware of the fact that there are differences, as otherwise you might miss an interesting opportunity to become even more productive.

Don't be dogmatic about Extreme Programming, RUP or any methodology.

Full agreement!

You have a better chance of improving your process gradually then you do by taking a dogmatic stance. For Example saying: "Use Cases suck. It is too complex. Let's just do User Stories" will not do much good in a RUP shop. Nothing can stop progress faster than making such a statement. Prefer gradualism. Most of principles of an Effective Developer can be flown under the radar with full support from management. Focus on gradual improvement not arguing or taking dogmatic stances. I agree that it is not as fun, but it is sure more productive.

I'd think that you also can introduce a new process in one sweep without being dogmatic. "Let's try full XP for a month and see what happens." Depending on the circumstances it could actually be more productive than gradual improvement.

[Stan James]

Use cases and user stories are interesting together. My team was mentored by Rational and did use cases much as you'd see in any RUP book.
Something that may not be written in stone but is often the expectation is that you can work and work on a use case and be "done" at some point. You might look for signatures of agreement from a number of stakeholders at this point.
Something very explicit in XP is that you do user stories one or a few at a time and gradually build up the same knowledge, tho usually not the same stack of documents.
I moved our team to a more iterative place, with estimates and assignments and tracking done on stories. Because we didn't want to shock all stakeholders too much, we kept use cases. But now we write them one story at a time. They are never "done" but grow from one iteration to the next.
I got to talk to Grady Booch a bit, and said "XP says a story is a promise to have a conversation, we say the use case is our record of the conversation" and he didn't strike me dead, so I figure it's a good line.

[Lasse Koskela]

Originally posted by Stan James:
he didn't strike me dead, so I figure it's a good line.

Grady Booch has been known to state that they didn't mean RUP to be the slow giant as most implementations are (Royce, anyone...).

[Michael D. Brown]

I wanted to thank everyone for their input. I saw through the thoughtfulness of the posts and through perusing websites that there are some great minds here at the Ranch.
To update everyone, I am currently Director of Software Development at a small VAR. So instead of convincing a customer to use a methodology, I am charged with defining it. It's going to be exciting to say the least.
I have taken everyone's comments into consideration and have decided to us a cafeteria style selection process for the final methodology the company will use. The great thing about it is that I can document my decisions and determine how they have helped or hindered the process as I create a J2EE implementation of the company's core application.
Joy!
Michael
PS. I am now deep into reading The Accidental Manager.
[ January 28, 2004: Message edited by: Michael D. Brown ]