I recently finished reading a draft of an
upcoming book on agile techniques and the author says something along the lines
of
“The only Gantt chart that makes any
sense looks like this:
Analysis |*************************************|
Design |*************************************|
Coding |*************************************|
Testing |*************************************|
”
(That’s supposed to be 4 bars all
extending the full length of the project.)
My immediate thought was that was a
picture of RUP! Draw those lines with a little waviness and a few trends up or
down and it’s exactly what RUP appears mostly to have been intended as.
--Mike
-----Original Message-----
From: Alan Shalloway
[mailto:alshall@xxxxxxxxxxxxxxxxx]
Sent: Sunday, December 15, 2002
10:23 AM
To:
scrumdevelopment@xxxxxxxxxxxxxxx
Subject: RE: [scrumdevelopment]
great article on agile/waterfall re rup
Mary:
I do see how you can do PSP in an agile way, but I don’t see how to do
CMM in an agile way. Also, the point is that the people who developed the
Unified Process _meant_ it to be
agile while the people who developed SEI-CMM did not. That’s my main
point anyway.
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: Mary Poppendieck
[mailto:mary@xxxxxxxxxxxxxxx]
Sent: Sunday, December 15, 2002
8:55 AM
To:
scrumdevelopment@xxxxxxxxxxxxxxx
Subject: RE: [scrumdevelopment]
great article on agile/waterfall re rup
Mike,
It strikes me that one could
substitute CMM or anyway PSP in your remarks below and about the same comments
would hold. There is always wisdom in these programs. Problem is,
when companies implement them, they focus on known demotivators (policy,
supervision, administration) instead of known motivators (achievement,
recognition, responsibility). Generally this is not so much the fault of
the program as it is the fact that the program readily lends itself to policy, supervision,
and administration, while in and of itself, the program does not force an
increase in achievement, recognition, and responsibility.
Mary Poppendieck
www.poppendieck.com
952-934-7998
Date: Sat, 14 Dec 2002
18:28:22 -0800
From: "Alan Shalloway"
<alshall@xxxxxxxxxxxxxxxxx>
Subject: RE: great article on
agile/waterfall re rup
Until a little over a year ago, I
admit not
knowing RUP very well and just
dismissed it as a heavy methodology. I
based this not on what I knew RUP to
be but on the fact that every
company I knew that followed RUP was
mired in a heavyweight process. I
even had a student who came to one
of my design pattern classes say -
"Please come to my firm, we've
just implemented RUP and now all I do is
documentation!"
I finally decided I better actually
learn something about it and read
Philippe's great book and Larman's
as well. At first I was skeptical -
did Rational _really_ suggest RUP
was agile? I finally had a great
conversation with Gary Pollice and
found out - yes!
My opinion of RUP has changed
considerably out of this (I still like
Scrum best) and showing companies
how to do RUP in an agile manner has
now become a possibility.
My point, however, is - since RUP
_is_ so mis-applied, I think it is
important to talk about this aspect
of it so people become aware that
this is _not_ what RUP is supposed
to be. Without exposing this at
every opportunity, many people will
continue to be under a
misunderstanding of what RUP
is. Personally, I loved this article and
think it was exceptionally written
and would love for many "heavy
weight" managers to read it.
Alan Shalloway, Sr. Consultant, CEO
office: 425-313-3065. mobile:
425-531-0810
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 the Yahoo!
Terms of Service.
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 the Yahoo!
Terms of Service.
