Loading ...
Sorry, an error occurred while loading the content.

RE: [scrumdevelopment] UP was Re: [XP] Agile 2.0

Expand Messages
  • Ken Schwaber
    Thanks for the slicing and dicing, Ron. Ken _____ From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
    Message 1 of 57 , Aug 3, 2006
    • 0 Attachment

      Thanks for the slicing and dicing, Ron.  



      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
      Sent: Tuesday, August 01, 2006 2:30 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] UP was Re: [XP] Agile 2.0


      Hello Scott,

      Thanks for your email. On Tuesday, August 1, 2006, at 1:58:28 PM,
      you wrote:

      > From my point of view he was pretty clear that he thought that AUP
      > 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?

      The EUP literature declares RUP "insufficient" , suggesting that EUP
      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.

      Randomly ...

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

      As I read that document, it does not cry out as Agile. It cries out
      to me as a heavily-documented flowcharted process creating roles
      that are likely to be identified as individuals. It shows managers
      driving everything.

      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?

      Ron Jeffries
      www.XProgramming. com
      Reason is and ought only to be the slave of the passions. -- David Hume

    • Ron Jeffries
      Hello Eb, Thank you for your email. On Wednesday, August 9, 2006, at 5:06:12 ... Well, my point really is that I think courses don t make anyone Agile. All
      Message 57 of 57 , Aug 9, 2006
      • 0 Attachment
        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 guess
        > 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)...

        Well, my point really is that I think courses don't make anyone
        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.

        Ron Jeffries
        Prediction is very difficult, especially if it's about the future. -- Niels Bohr
      Your message has been successfully submitted and would be delivered to recipients shortly.