RE: Scrum and RUP

I certainly would not try to do RUP-XP.  That "marriage" never made
sense to me and still doesn't.  I also agree that the powers that be at
Rational seem to miss the point of agile.  However, the Rational
consultants (or at least several I've talked to) do get agile.

I have also had the sentiment that "If I had my way, it would 
not have happened. But if 'twere done, 'twere best done well."  The
problem with many RUP projects is that many times the dev team want to
be agile while management wants to do RUP.  They don't really even care
so much about agile, but are following a mandate from above about RUP.

I know how I can make RUP agile, but I don't know how I can do XP under
RUP.  Also, I personally don't think doing XP is so important - doing
agile is.  XP is merely one of many ways to be agile.
 
Alan Shalloway, Sr. Consultant, CEO
office: 425-313-3065. mobile: 425-531-0810

Net Objectives' vision is effective software development without
suffering. Our mission is to assist software development teams in
accomplishing this through a combination of training and mentoring. 


-----Original Message-----
From: Ron Jeffries [mailto:ronjeffries@xxxxxxx] 
Sent: Sunday, December 15, 2002 12:48 PM
To: scrumdevelopment@xxxxxxxxxxxxxxx
Subject: Re: [scrumdevelopment] Scrum and RUP

The following are my personal opinions and do not necessarily reflect
those of
Object Mentor or anyone else for that matter. Or even mine as of
yesterday or
tomorrow.

On Sunday, December 15, 2002, at 11:53:07 AM, Ken Schwaber wrote:

> Let us hypothesize that having a Scrum plug-in for RUP is an idea
worth
> pursuing. Then I have the following questions:
> 1. How good was the effort at the XP plug-in. Does it help or hurt?
Did the
> greater distribution cause the essence of XP to be more widely
distributed,
> or did the translation of XP into RUP cause XP to lose it's "soul?"

The comments from Rational clearly did not reflect the soul. They do not
get
"agile" in my opinion. Some of them seem to get the idea of doing more
with
less, but the overall push of the company is to sell their services and
to sell
Rose and such. With IBM, if they wind up at IBM, this will only become
more true
in my opinion. Less process cannot become a goal of a company that wants
to sell
more process-oriented products.

Their philosophy, again in my opinion, is based in large-systems
experience,
old-style "up front" thinking, and a command and control orientation.

> 2. Given the meta model of a process within Rose, that is used to
generate
> RUP, how can an agile process be effectively described? The models of
> processes that we used in our process management software always
revolved
> around hierarchies or tasks, with the lowest level tasks having
estimates,
> roles, inputs, outputs, techniques and task descriptions. And, of
course,
> each of the roles, techniques, inputs, and outputs were further
described.
> Is this type of metaphor appropriate for agile processes, or does this
level
> of delineation lead to them being fodder for M/S project,for
"hands-off"
> management, and for robotic tracking of plans while ignoring
realities?

It is quite difficult to express XP inside the RUP. The issues revolve
around
the fact that the RUP has "slots" which need filling in: some of these
are roles
which must be reflected, and some are "artifacts" which need to be
connected
back to the process.

> 3. If the first two questions are adequately addressed, what is our
best way
> to proceed with the effort?

They will pay to have it done. If someone who really understands Scrum
does not
help them, they will do it themselves or hire some hack to do it.

So it's almost a moral issue. My involvement with the RUP XP plugin was
based on
my belief that it would be better with me than without me, and I think
it is.
Even so, it is still a long way from expressing what XP is.

BTW, I didn't make a dime on it, and don't expect to. If I had my way,
it would
not have happened. But if 'twere done, 'twere best done well.

Ron Jeffries
www.XProgramming.com
The rules are ways of thinking, not ways to avoid thinking.


To Post a message, send it to:   scrumdevelopment@xxxxxxxxxxx
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@xxxxxxxxxxx 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 




To Post a message, send it to:   scrumdevelopment@xxxxxxxxxxx
To Unsubscribe, send a blank message to: 
scrumdevelopment-unsubscribe@xxxxxxxxxxx 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/