R: Scrum and RUP

I'll try to comment.

Adriano Comai
www.analisi-disegno.com

> -----Messaggio originale-----
> Da: Ron Jeffries [mailto:ronjeffries@xxxxxxx]
> Inviato: domenica 15 dicembre 2002 21.48
> A: scrumdevelopment@xxxxxxxxxxxxxxx
> Oggetto: 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?

[AC]
To Ken:
I have seen the XP Plug-in, but I haven't analyzed it. If your question
means "how good it describes XP principles and practices", I'm not able to
give an answer.

To Ron:
But you seem rather skeptical about it.

>>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.

[AC]
There has been some debate about it in the extremeprogramming mailing list,
about 2 months ago. I remember Ron denying the Plugin lost XP soul. On the
other hand, I'm not sure how wide the distribution of the RUP Plug-in for XP
may have been, up to now.

To Ron:
It's true, less process cannot become a goal for Rational-IBM. But a more
effective process is a goal for many users of the RUP, both developers and
managers.

> > 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.

[AC]
I've not yet analyzed the Rational Process Workbench, the tool to make RUP
Plug-ins.
All I can say is:
- RUP has no estimates whatever
- RUP has no any manadatory role. Roles can be completely changed.
- RUP has no mandatory artifacts. Artifacts can be completely changed.
- The lowest level tasks can be at whatever level, you don't need to
decompose below the level you need to describe. I pull it just a little: if
a Sprint is a "task", you don't need to decompose it, if you don't think it
correct or useful.
- The same for roles: if a "team" is a role, you don't need to decompose it
further.
- I could easily think of mapping into a RUP Plug-in the drawing of the page
"What is Scrum?" at http://www.controlchaos.com , and the roles, tasks,
artifacts, guidelines described in Ken Schwaber and Mike Beedle book.

On the other hand, I think making an XP Plugin is more difficult than making
a Scrum Plugin: there are much more "disciplines" to change, adding and
removing (requirements, analysis and design, implementation, test, project
management) fo XP than for Scrum. In the case of Scrum, it seems to me it is
necessary to change a lot (adding and removing) in the project management
discipline, something in the requirements one. In the other disciplines,
there's only to remove.

> > 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.

[AC] If we think the hypothesis of the plug-in stands, we've got to
understand the business case for the project, the roles involved, the
project team, etc. In the meanwhile, I can obviously take a deeper look at
the technical how-to about the Process Workbench.


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/