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

Re: cmm and agile

Expand Messages
  • acockburn@aol.com
    In a message dated 4/1/2004 7:29:30 AM Mountain Standard Time, ... There is an implicit assumption lurking in this paragraph that XP is not formal. Indeed,
    Message 1 of 1 , Apr 1, 2004
      In a message dated 4/1/2004 7:29:30 AM Mountain Standard Time,
      extremeprogramming@yahoogroups.com writes:

      > I like Cockburn's two dimensional evaluation that he talks about for
      > Crystal - more people on the team and/or more damage from failure,
      > the more formal you need to be. I would either substitute or add
      > the distance between team members and between the team and customer
      > as another dimension. It fits my situation well.

      There is an implicit assumption lurking in this paragraph that XP is not
      formal. Indeed, I've heard this argument made many different times by many
      different people. They say that XP is informal; or XP is low ceremony.

      I think they are wrong. I think XP is very formal and is high ceremony. It
      is formal in that all the essential documents produced by XP are executable.
      Requirements are documented as executable acceptance tests. Designs are
      documented as executable unit tests. It is high ceremony because there are
      certain things that must be done as a team every day, every week, and every
      month. XP does not mean ad-hoc.

      The that is as stake (the more damage from risk) the more you need to write
      your unit tests first, write your acceptance tests first, and work in very
      short cycles with lots of stakeholder feedback. The more people you have on
      the team, the more you need communication, tests, short cycles, and lots of
      Agreeing with both of you. Adding distance adds communication complexity. I
      discuss it as a modifier on team size. The issue with team size is
      "coordination" and "communication". You can see that using remote teams add to both.

      The other dimenion is potential damage, as you both say. It bothered me for
      years that I couldn't find in my project debriefings any real change of habits
      as the risk of damage increased. I began thinking there was a hole in my
      reasoning (there is, I just haven't found it yet). But finally I found some

      Doing field tests on Motorola cell phone technology is easily done with agile
      techniques, unit tests, etc. However, doing a production run on Motorola cell
      phones needs more than just that. The test team should want everything nice
      and stable and unchanging for a period of time so they can test the holy
      bejeebers out of everything ... once the phone hits the market there's no room for
      adjustment or redeployment. Doing space shuttle and atomic power plants, we
      should want even more --- we should want large-scale or public inspection of the
      code and the tests.

      These are not ordinary requests, but they illustrate the vertical dimension.

      Bob is right (to my thinking) --- XP is formal, and with good TDD and
      automated regression test harnesses and pair programming, we can get much farther up
      the vertical dimension (the criticality) than with any other agile technique
      or method.

      The only place I disagree with Bob is that I didn't see in the paragraph an
      assumption that XP is not formal or is low ceremony. So it may be that we're
      really all just agreeing with each other.

      Alistair Cockburn

      "La perfection est atteinte non quand il ne reste rien a ajouter,
      mais quand il ne reste rien a enlever." (Saint-Exupery)

      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.