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

RE: [chicago-agile-dev] RE: [scrumdevelopment] RE: [XP] Scrum and XP

Expand Messages
  • Mike Beedle
    ... Lowell: I disagree. I feel it clarifies the purpose. The problem also is that is not only +more as you point out above, but in many cases is: +more
    Message 1 of 20 , May 15, 2002
    • 0 Attachment
      Lowell Lindstrom wrote:
      > > We use a different names for 2 main reasons:
      > >
      > > 1) out of respect for what XP and Scrum are,
      > > because we don't like to say that we do is
      > > XP or Scrum and then have someone pointing out
      > > that XP or Scrum don't do things like we do.
      > >
      >
      > I can definitely see wanting to avoid the "are you doing
      > XP(Scrum)? debate." But you are doing XP and Scrum,
      > plus MORE. What's interesting is the "more"
      > part, that variance, not the XP and Scrum. That is
      > where the attention should be. Naming the superset
      > distracts from that.

      Lowell:

      I disagree. I feel it clarifies the purpose.

      The problem also is that is not only +more as you point
      out above, but in many cases is:

      +more +modifying or specializing something in
      Scrum or XP. For example, there are highly specialized
      Scrum of Scrums in an XBreed environment, we don't
      only care about Product Backlog, but about many
      Backlogs with dependencies. So even when the
      spirit of Scrum survives, the meeting is structured
      around different buckets.

      Lowell Lindstrom wrote:
      > > 2) and because we like to remember,
      > > "special combinations" that lead to a desired
      > > specialized result. In the case of XP@Scrum
      > > is business value, and in the case of XBreed
      > > is reusability. So we abstract these special
      > > combinations with a name rather than tell people:
      > >
      >
      > Thanks! I understand a little better. Somehow I missed
      > that each had a different emphasis. I was under the
      > impression that they were both simply different
      > combinations of XP and Scrum.

      Unfortunately, Ken and I, and the people that we associate with
      are typically on the trenches, so we have had little time
      to explain things better.

      Lowell Lindstrom wrote:
      > The name proliferation seems not agile to me. It introduces unnecessary
      > complexity. Surely XBreed projects want business value and XP@Scrum
      > projects want reuse. A better approach is to emphasize only what
      > is unique, rather than the rename the whole set. What are
      > the set of practices that when added to what we know as
      > Scrum and XP lead to higher reuse? That is a set of practices that
      > warrants a new label, not the superset. Same with XP@Scrum. What
      > are the practices that when added to what we know as Scrum
      > and XP deliver higher business value? Call that XP@Scrum (or BVD).
      > If it is just XP, with Scrum replacing the planning game, just
      > call it "XP with Scrum as the Planning Game" or "Scrum using
      > XP Practices for the software development."

      Unfortunately, there are many modifications so it can't be
      expressed by something as simple as:

      "XP with Scrum as the Planning Game"

      That is a starting point, and in fact, that's more or less
      how XBreed started, but once the focus changed, the sentence
      became a paragraph, the paragraph became a chapter, and
      pretty soon you have something new.

      I suspect the same thing is going on with xp@Scrum.

      Lowell Lindstrom wrote:
      > > In terms of names consider this: Monkeys and Humans have
      > > a x > 99% overlap in their chromosome and gene sequences,
      > > yet, this difference yields to very different animals.
      > > However, as much as we are alike I don't think there
      > > is any human that likes to be called a monkey
      >
      > Nicely phrased! Yes, I am aware that egos are involve here ;-).
      > I just hope they can be kept in check enough not to
      > kill the movement. A proliferation of differently names
      > sets of methods that are basically identical has that
      > risk associated with it.

      Well, I didn't mean to say anything related to egos.

      My point was that simple changes in the meta-architecture of
      a system (genotype) can yield to big changes in the overall
      structure of the instances (phenotype), and that they
      may deserve a different abstraction - a different word.

      Actually, we did discuss "name proliferation" at our initial
      meeting at Snowbird, and we encouraged each other to explore
      and try new things without trying to "unify" things ;-)

      Diversity makes us stronger,

      - Mike


      http://www.hipaaccelerator.com
      We are hiring Java Developers, architects and project managers.
      http://www.e-architects.com

      http://www.xbreed.net
      http://www.agilescrum.com
      http://www.livingmetaphor.org

      http://www.agilealliance.org

      http://www.mikebeedle.com
    • Ken Schwaber
      Lowell, I agree with all of your sentiments. I lead with Scrum because I know it best since I m more of a product manager and project manager at this point
      Message 2 of 20 , May 15, 2002
      • 0 Attachment
        Lowell,
        I agree with all of your sentiments.

        I lead with Scrum because I know it best since I'm more of a product manager
        and project manager at this point than a developer. I probably couldn't lead
        with XP because of the change management required for the engineering
        practices. This doesn't mean that XP's engineering practices aren't needed!!
        When the engineering practices are weak, as they are at almost IT shops
        doing web development, I recommend XP and have recently been brining in
        buildmasters or scrummasters from ThoughtWorks to implement them for the
        customer while the project is underway.

        I can bring Scrum in and within 1 day have the team developing software,
        "the art of the possible." If their engineering practices are weak, the
        productivity is lower and the bugs are many. As the engineering practices
        improve, so do the increments of functionality. This way XP slips in bit by
        bit rather than being a big "let's study it."

        Ken

        -----Original Message-----
        From: Lowell Lindstrom [mailto:lindstrom@...]
        Sent: Wednesday, May 15, 2002 4:56 PM
        To: 'scrumdevelopment@yahoogroups.com'
        Subject: [scrumdevelopment] RE: Re: [XP] Scrum and XP


        > From: "Mike Beedle" <beedlem@...>
        > Subject: RE: Re: [XP] Scrum and XP
        >
        > However, let me focus on your question: "Is Scrum going to
        > end up just being part of XP?"
        >
        > Here is my take: not a chance.

        I agree with Mike. I don't see this happening, nor do I think anyone needs
        it to happen.

        > If anything, XP might eventually adopt a "full Scrum" approach,
        > and eventually get closer to a full gene mix of XP and Scrum.

        Mike, here I do not understand. Your response comes across to me as if you
        feel threatened, as if XP and Scrum are in some kinda of competition with
        each other. Perhaps I am misreading.

        You and Ken have had good experiences using practices from both XP and
        Scrum. I already see XP Teams naturally evolving to practices that greatly
        resemble parts of Scrum (Scrum or scrums, more formal management of stories,
        etc.). They don't call it Scrum because they have never heard of Scrum. I
        don't see why we care whether XP becomes Scrum, Scrum becomes XP, or
        everything is communicated under the umbrella of Agile Best Practices. To
        debate that seems to miss the point, which we all seem to agree is to find
        better ways to deliver business value through software development.

        Lowell

        ====================
        Lowell Lindstrom
        Object Mentor, Inc | www.objectmentor.com | 1-800-338-6716
        lindstrom@...



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

        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Brad Appleton
        I wonder if some of this can be addressed using ideas similar to what Alistair used in Agile Software Development and his Crystal Methodologies... It seems
        Message 3 of 20 , May 15, 2002
        • 0 Attachment
          I wonder if some of this can be addressed using ideas similar to what Alistair used in 'Agile Software Development" and his Crystal Methodologies...

          It seems to me that Mike has perhaps found a new "niche" or "family" of methodologies that mix XP and SCRUM together in project-specific ways based on some project-specific parameters for certain tradeoff conditions (optimizing for reuse versus for ???).

          I wonder where on the spectrum of Crystal methods the particular set of conditions are that lead to this 'family of methods' that has the intersection of SCRUM+XP as its basis? I think it is probably not a problem to have a separate name to identify this "space" rooted at the intersection, and having a name for specific instantiation that is optimized for certain conditions seems fine too so long as it isn't claiming to be a brand new methodology (rather, its a named variation or 'flavor' in this particular 'family' or 'subfamily' within the agile methodology space).

          We still need names for all these things, they just don't all have to be in the same namespace at the same level of abstraction/granularity :)

          On Wed, May 15, 2002 at 05:19:59PM -0500, Mike Beedle wrote:
          >
          > Lowell Lindstrom wrote:
          > > > We use a different names for 2 main reasons:
          > > >
          > > > 1) out of respect for what XP and Scrum are,
          > > > because we don't like to say that we do is
          > > > XP or Scrum and then have someone pointing out
          > > > that XP or Scrum don't do things like we do.
          > > >
          > >
          > > I can definitely see wanting to avoid the "are you doing
          > > XP(Scrum)? debate." But you are doing XP and Scrum,
          > > plus MORE. What's interesting is the "more"
          > > part, that variance, not the XP and Scrum. That is
          > > where the attention should be. Naming the superset
          > > distracts from that.
          >
          > Lowell:
          >
          > I disagree. I feel it clarifies the purpose.
          >
          > The problem also is that is not only +more as you point
          > out above, but in many cases is:
          >
          > +more +modifying or specializing something in
          > Scrum or XP. For example, there are highly specialized
          > Scrum of Scrums in an XBreed environment, we don't
          > only care about Product Backlog, but about many
          > Backlogs with dependencies. So even when the
          > spirit of Scrum survives, the meeting is structured
          > around different buckets.
          >
          > Lowell Lindstrom wrote:
          > > > 2) and because we like to remember,
          > > > "special combinations" that lead to a desired
          > > > specialized result. In the case of XP@Scrum
          > > > is business value, and in the case of XBreed
          > > > is reusability. So we abstract these special
          > > > combinations with a name rather than tell people:
          > > >
          > >
          > > Thanks! I understand a little better. Somehow I missed
          > > that each had a different emphasis. I was under the
          > > impression that they were both simply different
          > > combinations of XP and Scrum.
          >
          > Unfortunately, Ken and I, and the people that we associate with
          > are typically on the trenches, so we have had little time
          > to explain things better.
          >
          > Lowell Lindstrom wrote:
          > > The name proliferation seems not agile to me. It introduces unnecessary
          > > complexity. Surely XBreed projects want business value and XP@Scrum
          > > projects want reuse. A better approach is to emphasize only what
          > > is unique, rather than the rename the whole set. What are
          > > the set of practices that when added to what we know as
          > > Scrum and XP lead to higher reuse? That is a set of practices that
          > > warrants a new label, not the superset. Same with XP@Scrum. What
          > > are the practices that when added to what we know as Scrum
          > > and XP deliver higher business value? Call that XP@Scrum (or BVD).
          > > If it is just XP, with Scrum replacing the planning game, just
          > > call it "XP with Scrum as the Planning Game" or "Scrum using
          > > XP Practices for the software development."
          >
          > Unfortunately, there are many modifications so it can't be
          > expressed by something as simple as:
          >
          > "XP with Scrum as the Planning Game"
          >
          > That is a starting point, and in fact, that's more or less
          > how XBreed started, but once the focus changed, the sentence
          > became a paragraph, the paragraph became a chapter, and
          > pretty soon you have something new.
          >
          > I suspect the same thing is going on with xp@Scrum.
          >
          > Lowell Lindstrom wrote:
          > > > In terms of names consider this: Monkeys and Humans have
          > > > a x > 99% overlap in their chromosome and gene sequences,
          > > > yet, this difference yields to very different animals.
          > > > However, as much as we are alike I don't think there
          > > > is any human that likes to be called a monkey
          > >
          > > Nicely phrased! Yes, I am aware that egos are involve here ;-).
          > > I just hope they can be kept in check enough not to
          > > kill the movement. A proliferation of differently names
          > > sets of methods that are basically identical has that
          > > risk associated with it.
          >
          > Well, I didn't mean to say anything related to egos.
          >
          > My point was that simple changes in the meta-architecture of
          > a system (genotype) can yield to big changes in the overall
          > structure of the instances (phenotype), and that they
          > may deserve a different abstraction - a different word.
          >
          > Actually, we did discuss "name proliferation" at our initial
          > meeting at Snowbird, and we encouraged each other to explore
          > and try new things without trying to "unify" things ;-)
          >
          > Diversity makes us stronger,
          >
          > - Mike
          >
          >
          > http://www.hipaaccelerator.com
          > We are hiring Java Developers, architects and project managers.
          > http://www.e-architects.com
          >
          > http://www.xbreed.net
          > http://www.agilescrum.com
          > http://www.livingmetaphor.org
          >
          > http://www.agilealliance.org
          >
          > http://www.mikebeedle.com
          >
          >
          > To unsubscribe from this group, send an email to:
          > chicago-agile-dev-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >

          --
          Brad Appleton <brad@...> http://www.bradapp.net/
          "Education is the ability to listen to almost anything
          without losing your temper or your self-confidence."
          -- Robert Frost
        • Mike Beedle
          ... Brad: These are interesting thoughts indeed. Much to be worked by present and future agileers, - Mike
          Message 4 of 20 , May 16, 2002
          • 0 Attachment
            Brad Appleton wrote:
            > I wonder if some of this can be addressed using
            > ideas similar to what Alistair used in
            > 'Agile Software Development" and his Crystal
            > Methodologies...
            >
            > It seems to me that Mike has perhaps found a new
            > "niche" or "family" of methodologies that mix
            > XP and SCRUM together in project-specific ways
            > based on some project-specific parameters
            > for certain tradeoff conditions (optimizing for
            > reuse versus for ???).
            > I wonder where on the spectrum of Crystal methods
            > the particular set of conditions are that lead to
            > this 'family of methods' that has the intersection
            > of SCRUM+XP as its basis? I think it is probably not
            > a problem to have a separate name to identify this
            > "space" rooted at the intersection, and having
            > a name for specific instantiation that is optimized
            > for certain conditions seems fine too so long as
            > it isn't claiming to be a brand new methodology
            > (rather, its a named variation or 'flavor' in
            > this particular 'family' or 'subfamily' within
            > the agile methodology space).
            >
            > We still need names for all these things, they
            > just don't all have to be in the same namespace
            > at the same level of abstraction/granularity :)

            Brad:

            These are interesting thoughts indeed.

            Much to be worked by present and future agileers,

            - Mike
          Your message has been successfully submitted and would be delivered to recipients shortly.