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

Re: [scrumdevelopment] Re: basic question on SCRUM

Expand Messages
  • Keith Lancaster
    On many points we are actually in agreement. A couple of comments in line... On 8/25/05, Ron Jeffries wrote: ... I guess
    Message 1 of 17 , Aug 25, 2005
      On many points we are actually in agreement. A couple of comments in line...

      On 8/25/05, Ron Jeffries <ronjeffries@...> wrote:
      > I haven't found anything that points to any core XP literature or
      > site saying that the code is the documentation.

      I guess it depends on what you mean by "core" XP literature. I noticed
      a number of slide presentations where people were obviously trying to
      teach XP to organizations that made this assertion (not just in the
      book you cite). What you might consider is that for whatever reason,
      individuals and companies are often *interpreting* XP to mean the end
      of all (developer) documentation, just as some interpret RUP to mean
      that you are *required* to generate hundreds of documents before you
      code. Now if you happen to know anyone who writes books on XP who
      could emphasize this a bit more...:-)

      > One reason is that the traditional methods really intend that we
      > should document, say, the design, because we're going to build the
      > design first, using all those geniuses we apparently have somewhere,
      > and then hand it off to code monkeys to build according to the
      > design.

      This characterization is unfortunate, and frankly reflects a bit of
      the attitude that kept me from looking at agile processes for a long
      time. You just did what you attribute to the author who was critical
      of XP - you set up a straw man to knock down. I've worked in
      environments from ad-hoc to agile to RUP. I've certainly encountered
      "architects" with a bit of that attitude from time to time, but for
      the most part regardless of process people were generally trying to
      apply methods that they thought (rightly or wrongly) would stand the
      best chance of bringing success to their project.

      > Agile methods build design and code together, using normal humans
      > throughout.

      Actually, this is a point I am not yet certain about ("normal
      humans"). There seem to me to be underlying assumptions to agile
      practices, including Scrum, about the skills and character of the team
      members on an *effective* team. XP requires a disciplined approach to
      software development. If "normal" equates to "average", and I look
      back over the developers I have worked with across the years, I can
      identify very few that would or could thrive in that kind of
      environment. There are others that from a cultural standpoint might
      find it difficult to work in a team environment such as Scrum where
      everyone shares responsibility and is expected to be assertive at
      least to some extent. I would suspect that in many cases that agile
      practices tend to weed out "average" developers resulting in teams of
      people who are a bit above the norm.

      Just a final note: I *am* a strong advocate of Scrum and many of the
      practices you promoted in XP, and I spend a good deal of time daily
      working to get them implemented in my current project (RUP based).
      What I have found most intersesting is that when the team searches for
      solutions, they almost always trend toward everything that agile
      advocates: minimum documentation, more communication, less restrictive
      processes, lighter-weight design methods, etc.
      Doing extensive unit testing and TDD ..... not so much, but I'm
      working on it. :-)


      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
    Your message has been successfully submitted and would be delivered to recipients shortly.