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

334RE: [scrumdevelopment] RE: [XP] Scrum and XP

Expand Messages
  • Ken Schwaber
    May 15, 2002
      The reason why we go through the extra effort to rationalize the overlapping
      names between Scrum and XP is that Scrum terminology is more understood,
      more business natural. It fits with business project and product managers.
      XP is more OO and engineering-centric and feels alien to this audience. It's
      our way to get agile used with XP engineering practices. It eases the
      implementation of XP and allows us to scale XP elsewhere in the

      -----Original Message-----
      From: Lowell Lindstrom [mailto:lindstrom@...]
      Sent: Wednesday, May 15, 2002 10:53 AM
      To: 'extremeprogramming@yahoogroups.com';
      Subject: [scrumdevelopment] RE: [XP] Scrum and XP

      > -----Original Message-----
      > From: Mike Beedle [mailto:beedlem@...]
      > Lowell Lindstrom wrote:
      > > I can't seem to find a substantial difference between
      > > the XP Planning Game and Scrum. There are subtle
      > > differences, but if the team is adapting their
      > > work as they proceed, I can't see why I starting
      > > with one versus the other would have make any
      > > difference in the outcome of the project.
      > Lowell:
      > Your assessment is correct. However, there is a glitch:
      > the planning game is like Scrum, but Scrum has a larger
      > scope than the planning game. Let me explain.
      > [background clipped.....]

      I appreciate the background. I think it gives some explanation as to why we
      have two sets of practices that are so similar, yet have different names.
      For the practitioner, I don't believe that the historical relationship
      between XP and Scrum are important. My main point was that if you are
      evolving your practices, XP Planning (or Scrum) will evolve to include the
      parts of the Scrum (or XP) that it needs. I don't need to confuse the
      process by introducing Scrum terminology (XP Planning terminology). From
      the first XP Immersion course, when the questioned was raised about
      documentation and other "stories" that don't end up as software tasks, the
      answer has been "if you need them, you can make them stories and plan them
      with the planning game." Adapt as you need based on feedback from the

      They will evolve to the same result in practice without the shift in
      terminology. The XP@Scrum thing seems forced to me, unless I am in an
      existing Scrum shop. If I am with a team that is new to both, I am
      introducing un-needed complexity with redundant practices. XP Planning is
      sufficient in this case.

      I am not advocating XP over Scrum or vice versa. It is the combination
      that, to me, that has unneeded complexity for the new team.

      > However, when all sort of things start to change, it is probably
      > best to move to Scrum because Scrum provides and agile
      > management framework to manage _all_ of the activities
      > of many related projects at all levels of the organization.

      I am unclear why I need to rename everything when the practices are
      basically the same. Why is it not sufficient to simply keep the XP Planning
      terminology, in this case, and use the practices on non-functional stories?
      This seems much more simple to me. I just don't see much benefit to balance
      against the cost of re-learning. This becomes particularly important in
      larger organizations.

      > This difference is in fact the source of inspiration
      > for what we practice at Hipaa Accelerator and e-Architects:
      > XBreed, which is Scrum for management, XP for engineering,
      > Alexanderian ideas, and a few new original ideas mixed
      > throughout.

      Did you consider expressing XBreed as simply additional practices to Scrum,
      XP, and Patterns? Having yet another agile method that primarily overlaps
      with others seems like forced complexity. If we were talking about code,
      wouldn't we refactor these to avoid the duplication? It feels like we are
      going to brand a new methodolgy with every project rather than grow and
      adapt the toolkit of agile practices as we learn more and apply these ideas
      to new domains and technologies.

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Show all 20 messages in this topic