RE: [scrumdevelopment] UP was Re: [XP] Agile 2.0
Thanks for the slicing and dicing, Ron.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Ron Jeffries
Sent: Tuesday, August 01, 2006 2:30 PM
Subject: Re: [scrumdevelopment] UP was Re: [XP] Agile 2.0
Thanks for your email. On Tuesday, August 1, 2006, at 1:58:28 PM,
> From my point of view he was pretty clear that he thought that AUPThe EUP literature declares RUP "insufficient" , suggesting that EUP
> and EUP were prescriptive. He at least implied it. That might be
> true of EUP but it isn't of AUP. Although to be fair, I don't
> remember claiming that EUP was an agile process so why is it being
> criticized for not being agile?
is "more" than RUP. RUP may or may not be intended to be
prescriptive, but it bloody well /is/ prescriptive on the ground.
EUP is also trademarked, which IMO is worthy of question if not
As for AUP, the home page says that if you are looking for something
"between" XP and RUP, then AUP is "likely" for you. XP is in fact an
instance of RUP, which makes me wonder just what "between" might
mean, and why, of all the things we can imagine between XP and
full-on RUP with all bells and whistles, AUP is the likely
The so-called "disciplines" of AUP are defined by huge and complex
diagrams showing roles I've never heard of before, and a plethora of
little arrowed boxes representing activities. The text does say that
you don't need to do everything in the list, but seems to give
little guidance as to when and when not. To be safe ... should I
create a thing, or not create it? Too many people conclude that they
should, if RUP is any example.
Why, by the way, AUP at all? RUP is perfectly adequate to describe
essentially any iterative process. Surely AUP is an instance of RUP,
but it seems that AUP is presented as an /alternative/ to RUP, not
as a way of doing RUP.
The workflow for "Implementation" appears to be phasist, and
requires six documents that are not conventionally "official" Agile
docs: (requirements model, design model, usability guidance,
enterprise development guidance, proof of concept prototype, and
defect report). It creates a new role, "Agile DBA".
The workflow for "Testing" also seems manifestly phasist to me. It
again shows more than one model in its picture, thus in effect
requiring those models to "exist". This blesses modeling -- which is
consistent with your position ab initio -- and while there is lip
service to doing only what's necessary, on the ground that seems to
turn into "a lot", not "a little". This page creates yet another
role "Test Manager" that I've never heard of before.
Having a separate workflow for development and testing isn't
obviously in line with Agile principles, by the way.
I could go on ...
> He also indicated that the people behind those methods don't seem toAs I read that document, it does not cry out as Agile. It cries out
> get it. I'm among the people behind those methods, and arguably the
> primary person behind them, so yes, I may have jumped to the
> conclusion that I'm being attacked.
to me as a heavily-documented flowcharted process creating roles
that are likely to be identified as individuals. It shows managers
The Inception phase (I thought that Agile != phased, by the way)
does not include software as its exit criterion.
Neither does Elaboration.
In the Construction phase, the software is built and tested. Until
now, I thought that starting with analysis, proceeding to design,
then building the software was called "waterfall", not "Agile".
In the Transition phase, we schedule rework. I thought that rework
was a part of every part of Agile, not just some final "phase".
Well, this is just off the cuff. But it doesn't read like "Agile" to
me. I can see how I could perhaps fake this process while doing
Agile, but I'd have to be faking a lot of people and a lot of
documents, and I'd have to be coding in at least two "phases" where
it's apparently against the rules.
How say you?
Reason is and ought only to be the slave of the passions. -- David Hume
- Hello Eb,
Thank you for your email. On Wednesday, August 9, 2006, at 5:06:12
PM, you wrote:
> Courses may not be for you - after all you give 'em, and I guessWell, my point really is that I think courses don't make anyone
> you've given so many maybe it feels like they don't have the impact
> you once hoped they would? Though I'd wager that they are helpful for
> those of us in need of some guidance. I did a CSM last October and it
> was the beginning of really exciting journey for me, so far it's led
> me here (amongst other places)...
Agile. All they do -- and this certainly has value -- is offer ideas
which people might try. As you say ... the course is the beginning
of a journey. But it's the journey that matters.
Prediction is very difficult, especially if it's about the future. -- Niels Bohr