Professional Documents
Culture Documents
Browse A ll Microsoft A pple Digital Living Hardware Software OS Storage Database Security Programming Web Development Networking Other
Stay Up To Date
Tags: Software Methodologies. Add Tags
669
Zones: Software/Systems Design, Business Management Software, Microsoft Project Project Management
Software 15.2K follow ers
My Favorites
Back to Previous Page View Solution
Quickly Reference Your
Favorite Zones
Add Edit
Assisted Solution ID: 25129237 Author: jaime_olivares Date: 18/08/09 07:29 PM
RUP is a collection of methodologies, more process oriented, while SCRUM is a single methodology Software Design
more developer oriented.
Since they are not antagonist, both can work together, as explained here: Week Month Year Overall
http://www.ibm.com/developerworks/rational/library/feb05/krebs/ 1. TommySz 11,600
GENIUS
Member Profile
Author Comment ID: 25129970 Author: srikanthrad Date: 18/08/09 11:11 PM 0 Expert Points Yesterday
2. capricorn1 4,000
Was this comment helpful? Yes No 3. DarrenD 3,800
4. Gertone 3,500
I agree that they are not antagonistic approaches. But, what i understood over research in google is 5. marklorenz 3,000
that
RUP is for the people who knows exactly what they are doing in advance, however requirements can 6. mplungjan 2,800
change in each phase when these iterations are developed to cope with the changes but the 6. murphey2 2,800
changes are not allowed to progress after each phase is complete.
8. phoffric 2,500
where as Scrum is required when requirements constantly change and we are obligated to iterate
9. gurvinder 2,220
and incorporate the changes in the software development as the development progresses.
10. mkobrin 2,000
Please correct me if I am wrong.
10. Nash2334 2,000
10. vrluckyin 2,000
10. sarabande 2,000
Expert Comment ID: 25130034 Author: jaime_olivares Date: 18/08/09 11:29 PM
10. amit_n_p 2,000
If I am right, in case of Agile if requirements change in the middle of Construction phase. Should we
wait until the next RUP phases begin starting from Inception? Unlike the SCRUM where the
wait until the next RUP phases begin starting from Inception? Unlike the SCRUM where the
requirements can be changed after current sprint which is kind of short time.
Personally, I would recommend RUP for large, high-value software projects (such as complex
software products), and Scrum for smaller projects (of any kind), especially projects that require
incremental delivery.
Note that the fundamental idea behind Scrum is empowering the team, making it fully autonomous
and responsible. This can be disruptive in some organizations.
On the other hand, RUP is a "structured" process that gives the power to... the process. This is often
desirable in large organizations but can reduce "nimbleness" and creativity.
As for your question on requirement management, Scrum indeed freezes requirements only for the
duration of each Sprint (usually 15 to 30 days), but that's because Scrum by definition does not
guarantee the contents (features) of the Release in advance. Basically, a Release contains... what
could be delivered in the Release timeframe.
RUP also allows requirements to be taken into account during the Construction phase, but the more
you allow that, the more unpredictable your project becomes, which can be a problem for projects
that choose RUP over Scrum for its predictability.
I like to add to the excellent explanation of Defi0 that RUP is capable of delivering software in a
demand-supply organization (whereas the supplier has a contract to deliver software for the
demanding business), because in RUP it is possible to organize progress and changes in a rigid way
so both parties in the organization keep on track during the process. Using SCRUM in a demand-
supply situation will be a huge challenge, since every sprint can (and will) stir up previous
agreements. My experiences tell me that business decision making bodies are commonly not that
flexible.
Another point of consideration is that SCRUM is a way of working that can easily be adopted, also
for a single project. RUP to the contrary will take more time to adopt as one needs to start with
what NOT to use of the 32 roles, 200+ templates and accompanying workflows in your organization,
then have everybody (i.e. everybody, including management, customers etc) put their mindsets in
the same RUP direction. Only when this is put right, you may (or should) start with your first
Inception phase. Any attempt to introduce RUP fpr an standalone project and start using it before
organizing it, fails.
Author Closing Comment ID: 31617400 Author: srikanthrad Date: 19/08/09 07:34 AM
Just an additional note: there are variants (deviants?) from RUP that are more agile and less
complex, such as AgileUP or OpenUP (http://epf.eclipse.org/wikis/openup/). The latter is actually
based, in part, on a subset of RUP donated by IBM/Rational.
This question has already been closed and has had points assigned. Post additional comments only
if you want to clarify or comment on the solution. You can also ask a related question.
Comment:
Share:
What is this? Facebook Twitter LinkedIn
Preview Submit
Shorten URL | Help | About Us | Contact Us | Terms of Use | EE Blog | Internet Rank | Privacy Policy | Site Map
Copyright 1996 - 2011 Experts Exchange, LLC. All rights reserved.