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

Re: [XP] Article on XP pathologies?

Expand Messages
  • BenAveling
    Hi Paul, A quick google for {xp process smells } turned up the following: Recognizing and Responding to “Bad Smells” in Extreme Programming Amr
    Message 1 of 52 , Jul 29, 2005
      Hi Paul,

      A quick google for {xp "process smells"} turned up the following:

      Recognizing and Responding to “Bad Smells” in Extreme Programming
      Amr Elssamadisy & Dr. Gregory Schalliol

      "We have identified areas of trouble in the
      entire life cycle, including analysis, design, development, and
      testing. For each practice we identify, we discuss the solution we
      implemented to correct it and, more importantly, examine the
      early symptoms of those poor practices (“bad smells”) that project
      managers, analysts, and developers need to look out for in order
      to keep an XP project on its swifter track."


      aka http://tinyurl.com/dha5l

      Good luck, Ben

      Paul Butcher wrote:
      > Hi - I'm hoping that the group can offer me some help with the
      > following:
      > I am looking for an article which describes "XP Pathologies".
      > Specifically, I'm looking for a list of ways to tell that your local
      > implementation of XP is broken and needs remedial action.
      > I've had a hunt through the various XP books and websites, but can't
      > find quite what I'm after - I can't believe that it isn't out there
      > though!
      > Background:
      > I've recently been contacted by an ex-colleague who knows that I
      > have run an XP team in the past. Her organisation has recently moved
      > to XP (or at least they *think* that they have). She has described a
      > set of pathological behaviour to me which is frankly scary:
      > - No well defined customer
      > - Customer not involved because they "don't have time"
      > - "Stories" defined at a technical level, rather than something
      > which is meaningful to the customer
      > - Developers scheduling stories rather than the customer
      > - No planning at all beyond the current iteration
      > - No agreed units for story estimates
      > - No "coach" role
      > - etc. etc. etc.
      > Before they can even begin to address all of these issues, they need
      > to accept that they have a problem. The best way to do this would be
      > if there was a website or book that she could point to and
      > say "look - it says in here that if you're not doing <foo>, then
      > you're not doing XP", or better yet "look - it says in here that if
      > you experience symptom <bar> then you need to take remedial action
      > <baz>".
      > I know that this kind of thing is distributed throughout the XP
      > literature, but what I'm ideally looking for is a single collection
      > of XP pathologies which they can look at (my guess is that they're
      > hitting a large proportion of them!).
      > Thanks in advance for your help,
      > paul.butcher->msgCount++
      > Snetterton, Castle Combe, Cadwell Park...
      > Who says I have a one track mind?
      > To Post a message, send it to: extremeprogramming@...
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
    • Edmund Schweppe
      ... I rather doubt *that*, if for no other reason than that I Have That Pattern myself. On the other hand, it s probably *easier* for some teams to blame the
      Message 52 of 52 , Aug 5, 2005
        Ron Jeffries wrote:

        > It just seems very odd to me that a team would be going along, not
        > getting good results, and then say "The book is wrong," rather than
        > "We must be doing something wrong."
        > Maybe I'm the only person most of whose problems seem to come from
        > his own mistakes ...

        I rather doubt *that*, if for no other reason than that I Have That
        Pattern myself.

        On the other hand, it's probably *easier* for some teams to blame the
        book, rather than themselves, when confronted with not-good results.
        When confronted with outright failure, it's even easier to lay the blame
        on "the book", especially since books don't tend to talk back and
        challenge hidden assumptions.
      Your message has been successfully submitted and would be delivered to recipients shortly.