Agile vs. RUP

At our company we have these meetings, where people from the same competence in a region come together to talk about all kinds of stuff, from business related to more fun related stuff. Because I went to the Dutch Developer Days 2005 with Edwin Waegemakers, we were asked to do a little presentation. We decided to give three small presentations, one about Team System, one about integration strategy and one about Agile Development. I would do first and last.


I’ve written about the Agile presentation at DevDays before and planned to use it in my own presentation, but a little less on the archetypes and a little more my personal experience. The plan was to bring it lightly and at the same time trigger our RUP ‘specialists’ as an Agile hooligan, and I can say it worked pretty well. I placed Agile strongly against RUP, although in practice this of course isn’t the case. Or at least not as hard as I had put it.


Agile vs. RUP
For a lot of developers documentation can be a drag to write. I have a personal experience on a project I joined, where they over-used RUP. Normally you get a pile of documentation of about 2″ high. On the project, I got a pile of about 10″ high. If I wanted to read that through, before actually doing something useful. The project had just started, and there wasn’t anything in it like functional specs. Just project guidelines and rules and technical visions, etc, etc, etc. So I used that in the presentation, with the Agile tenet to produce working software over extensive documentation. I highlighted extensive, as some people got the idea Agile has no documentation at all. That triggered some reactions!


Fun thing was, that our director just had seen a presentation last week, where RUP was presented as thรฉ answer to all problems in projects, sort of speak. This week I presented it as if RUP was about just documentation, and Agile development would really work. His conclusion was that now he knows he’s getting old, as he had never seen (technological) advancements update so fast. Last week RUP was everything, now it’s already outdated and replaced. ๐Ÿ˜‰


Project swing
Of course Agile isn’t a replacement for RUP and you cannot appoint one as a clear winner. I don’t think that’s necessary either. I think RUP is great, but you have to have experienced people doing RUP projects as you don’t want to overload everyone with documentation, but also have to carefully look at what the customer wants. RUP also uses iterations, but for some reason I have the feeling Agile development can better understand and react to what the customers needs, not what he thinks he wants. That comes to show in this funny picture of a swing. It’s funny to see how everyone within a project has (or can have) a different view on the swing. I think it’s hard to get the same swing in every picture. But my believe is, it’s much harder to retrieve from a customer to what he really wants and needs. To get the same picture in how a customer explains it and what a customer really needed, you need good iterations and a lot of communication. For some reason, I have the feeling communication in RUP is more through documents where as in Agile it’s face to face communcation between the customer and the entire team. And I think that’s an important difference.


Of course everything should still be managed, also documentation. ๐Ÿ˜‰
I’m particullary interested in how to manage the customer and/or final deadline. Once the customer gets the hang of changing and adding functionality, how can we manage them and the project so that we can deliver what we promised up front, and still meet some final deadline. Where is the line, between making agreements with a customer, and kind of just see what happens?


For those who want to know more about Agile Development :


You may also like...

10 Responses

  1. Jan Schreuder says:

    I’m in a project at the moment where they use SCRUM. From what I can see, it works fine, as long as your development requests are well-defined. This still means, that the customer needs to know what he wants (which is sometimes only partly true). It also requires development teams that are capable of extracting all missing information at the start of a SCRUM period.

    The problem with any type of development method is getting the requirements straight. Once you have that, you can decide which development method can be used. I’ve been in (semi)RUP projects, and that method worked.

    But the SCRUM method I have to use now is fine for the project I’m in. We need to implement small functional components for each SCRUM and most things are functionaly clear.

    It’s just that every new method seems to make the older one obsolete. And it takes time to see, that each has it’s own use.

  2. Ramon Smits says:

    Goede post gozert ๐Ÿ˜‰

  3. Over here RUP should’ve been the holy grail for all the projects. But our experience is that you need to have an experienced RUP projectmanager to make sure RUP is used as it supposed to be. So it doesn’t need to be an artifacts hell that people think it is, but you need experience to see that.

    I’m more of an XP/Agile kinda guy. And I believe that programmers who love to write documentation is a paradox. But as with RUP you need experience to see how much documentation is good enough to bring a project to an end succesfully.

    RUP is a very well documented, and Rational is very willing to sell you the "right" tools to do the job. I think in the Agile world you’re more dependant on the solution suppliers who have experience with implementing the Agile methodology.

  4. blyons says:

    hiho,

    The branded Rational Unified Process provides a ton of artifacts that a team can use when developing software. And there is little talk on collaboration or even how people are expected to work together. The early version of SPEM (the Software Process Engineering Metamodel from the Object Management Group) used to describe the process leads one to think of a situation where “I do task X alone and create artifact A, you then pick up artifact A and do task Y alone which produces artifact B, then someone else…”.

    That is not how it has to go, but the content provided by that version of the Unified Process can lead people to think of it that way.

    A group of people have been authoring an open source version of the Unified Process that takes an agile perspective. It has the end-to-end process structure recognizable from the Unified Process. It treats it as lightweight as possible. It includes guidance on various collaborative and other humanistic perspectives of developing a system. It includes roles for the sake of defining required skills, but does not have a strict perspective on roles or top-down tasking (i.e. promotes self-organizing teams). It folds in various agile techniques such as TDD, Refactoring, Continuous Integration, and even applies a Scrum-like technique for project planning.

    You can download it at http://www.eclipse.org/epf/ of view the 0.9 version of it published at http://www.numbersix.com/openup/.

    ——- b

  5. Great post,
    agile is definitely about getting the work done, while RUP can help with some larger scale structure necessary to manage work between teams, “non-agile” users, modeling larger scale systems and interfaces, etc.

    RUP is certainly lacking in some of the day-to-day commonsense delivery practices, in my mind this is where agile steps in and provides great value.

    I tend to combine both in most of my projects. I just finished posting on the [email protected] agile over RUP

    Free to comment or give feedback
    regards
    Jeff Anderson
    http://agileconsulting.blogspot.com

  6. Ramesh Babu says:

    The following is very well said by the Author. I totally agree with that.

    “For some reason, I have the feeling communication in RUP is more through documents where as in Agile it’s face to face communcation between the customer and the entire team. And I think that’s an important difference”

  7. pnb says:

    It also depends on managing in-house projects vs. managing external clients. In later case business is not readily available for discussion. When dealing with external clients, budgeting and scoping is way important and need to be precise and estimated well in advance. For in-house project scope and budgeting is relatively lenient (my experience).
    As Dennis said,getting requirement straight is important. With Agile if Project Manager is not good negotiator then small requirement turns out to be never ending. Documentation is must (even in mail is enough) but just verbal communication leads to many bad things. Agile needs very sound (technically and functionally) developers. Every one needs to deliver from day 1. In case of lateral hire, it may not always.

  8. Ahmed Muhammad Alam says:

    Yes I’m agreed with you that Agile save time but the thing is that, what I have experienced in the industry that too much documentation regarding the project will be painfull the new one and too less is also having the same meaning.

    If you follow Agile with too less documentation and incase anyone has left the company on urgent basis and you have to plug someone else. If you haven’t sufficient documents about the project than how the new person can adjust himself or herself in the project without having documents.

    Definitly the above management didn’t waste their time to describe about the project and even you don’t.

  9. Renuka says:

    This is a great discussion!I am a Software QA Engineer and yet to experience the Agile process,and most of my experience has been in the medical device field where documentation is required.I have worked in semi-waterfall and RUP environment, and wonder how design/coding can begin with few requirements as in Agile.Then I realize on reading several articles that Agile is a solution for changing or fewer requirements, and strongly agree that the engineers working in Agile require the skill of requirements-extraction(but to some extent it is also required in other methodologies),however, having though it is a solution for changing requirements, are the user stories not documented at all?Or they are documented but not as much as in RUP or in waterfall?How can then one know why we developed this and this two years back?I somehow am not able to let go the ‘feel-good’ factor that documented requirements provide..and thats why feel that neither is Agile complete not is RUP, perhaps a hybrid of these would be more useful..

    -Renuka

  10. Renuka says:

    Oh and I would like someone to comment on what I said above, because though everyone says that Agile is a better methodology, I dont seem to get convinced about ‘undocumented requirements’ and I want someone to convince me about it..or perhaps its because I have not really worked in an environment where requirements changed rapidly.

    -Renuka

Click on a tab to select how you'd like to leave your comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.