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

Re: Who cares about methodologies?

Expand Messages
  • aacockburn
    ... time. ... Nice questions ... Most of what I know about Methodologies I learned when I joined the IBM Consulting Group in 1991 – it was chock full of
    Message 1 of 89 , Mar 1 1:39 PM
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Charlie Poole" <xp@...>
      wrote:
      >
      > I haven't cared about specific (named) methodologies for a long
      time.
      > So I asked myself, who does care?
      >
      > ... carefully-conducted studies of how teams actually work, the
      > gain would be enormous.
      >
      > Now a methodologist might pop in here and say that's what we
      > do - or try to do - and you, Charlie, are simply expressing a
      > very common misconception about the study of methodologies.
      > Should there be such a person on the list, my answering
      > question would be "How come this misconception exists?"
      >
      > Charlie
      >

      Nice questions ... Most of what I know about "Methodologies" I
      learned when I joined the IBM Consulting Group in 1991 – it was chock
      full of card-carrying methodologists – in fact that was the entire
      purpose of our group. I'll tell you what /they/ said back then (to
      the extent I can recall back that far).

      Also, I'll say what the Scandinavian school of methodologists (super
      star example is Lars Mathiassen who got 2 doctorates in software
      development methodology! He was one of my coaches for my Dr. Philos.
      thesis). Also, I'll describe what I did in terms of those studies
      you refer to and how that interacts with the topic of methodologies
      (this was actually the topic for my Dr. Philos thesis, see it online
      on my web site).

      However, first, the word methodology has oodles of slightly different
      meanings, and the value of each is slightly different.

      Lars Mathiassen and co. use the word "method" instead
      of "methodology", and the connotation is slightly different. "Method"
      is something like "technique". Lars and co. like to say that a method
      is like a ladder that you use to climb up to a higher platform – once
      you're up there, you no longer need the ladder and can discard it.

      TDD is a "method", CRC is a "method", the "Rumbaugh modeling
      technique" is a method, and so on. Once you learn and internalize
      them, you don't notice or care if you are using them. (This is the
      Shu-Ha-Ri progression, see <link>).

      This is what I believe you are referring to when you write: "I
      realize I haven't cared about specific (named) methodologies for a
      long time."

      That's all fine, but that's really taking about techniques. Jeff
      Patton writes, "I have a bunch of tricks I use, and then someone asks
      me to teach them to him/her, and suddenly I have to come up with a
      Shu-level description for a trick ... and then it gets a name, and
      people start to copy it and quote it and ... And all it ever was was
      a trick I used on occasion."

      This is a useful way to look at methods or techniques. And here you
      are correct to "Learn it and Leave it".

      But what about "methodologies"?

      A methodology is (for one view of the term) a coordinated set of
      methods and techniques. That is, it's a macro-method.

      In this sense, all the stuff about "Learn it and Leave it" apply.
      That would be baseline XP, baseline Scrum, baseline DSDM, baseline
      FDD. Baseline Crystal Clear, too, although I designed that one to
      potentially cross the next boundary.

      However, the macro-method thing has a particular advantage, the one
      touted by the methodology experts in the IBM Consulting Group – it
      sets up a vocabulary that can be taught to and shared by everyone
      involved.

      Scrum is hitting this point these days – a very-large-company guy
      told me, "What's nice about Scrum is that we can bring people
      together from all over the world, and they know what a backlog is, a
      daily stand-up, a sprint, etc, so they can just started working
      together." Someone joining the group would ask, "How long is your
      sprint? When do you do your daily stand-up? What constitutes 'done'?"
      and then they're off and running.

      The next, and my favorite view of "methodology" is "the set of
      conventions the people agree to follow." I like this because it is
      easy to understand, easy to document, it naturally captures the drift
      of conventions over time, and you will never outgrow it.

      You can't "Learn and Leave" your group's conventions – they're alive
      and always in play – they're a social construction that you must
      attend to daily / weekly / whenever.

      This definition meshes nicely with the macro-method, in the following
      sense... My old boss at the IBM Consulting Group told me, "When you
      place an ad in the paper for a new person, what you write in the ad
      is an artifact of your methodology." That is, you write, "Someone
      with Scrum / XP / Modeling / Agile PM / Ruby / <whatever> skills",
      and when that person shows up you say, "You'll be sitting here,
      working with these people, taking information from those people,
      giving things to those other people, etc.".

      All of that is the /result/ of your set of conventions (possibly your
      macro-method, depending on how tight you rmacro-method is).

      I hope you are registering at this point that outside of Andersen
      Consulting's old Method One, we have left "named methodologies" long
      ago. We're in the unnamed space, the "here's what we do, it doesn't
      really have a name." XP isn't sufficient to cover this space, Scrum
      isn't, even DSDM isn't. The set of conventions we/you follow is far
      richer, more detailed and more specific than can be written down by
      any but the largest, centrally organized and probably DoD
      organization.

      When you play in this "set of conventions" space, then a new topic
      arises for named, published methodologies: What subset of the total
      set of conventions does it cover?

      XP1e, for example, named quite a lot of stuff. XP2e names more, if
      you choose to use them all. But there's still lots of stuff left out
      that you need to take care of (code formatting conventions? test
      naming conventions? Exactly when you do stand-ups and reflections?)

      As a result, when I write "a methodology is the set of conventions
      the team agrees to follow", this is the transient, just-for-this-
      iteration, never-written-down-but-still-understood, one-off,
      transient methodology --- I'll call this an instantiated methodology.

      Then there's the published thing – a chosen set of conventions that
      might apply over multiple iterations, multiple teams, maybe even
      multiple projects. Those are the "brand" methodologies that Ron keeps
      trying to quash.

      Knowing all that, I wrote Crystal ... what the heck is that?

      First, I asked myself what subset of conventions might possibly be
      reusable across teams ... and I got, basically, the empty set.

      So I asked myself "What is important?" and I came up with some
      principles, some theories, some graphs of "this-trades-off-with-
      that". Those are Crystal.

      When I went to Crystal Clear, I started from the most important set
      of patterns that I felt could pass the cross-project-conventions
      test, exactly as has been discussed in this thread. I came up with 13
      that might be reusable ... but the word "pattern" turns out to be a
      synonym for two, possibly different things: properties, and
      strategies.

      When I examined the 13 patterns I was inclined to stuff into Crystal,
      I found 9 properties and 4 strategies. Since I think that strategies
      are project- and situation-specific, I removed those and put them
      into the Strategies chapter. I paid attention to Steven Covey and
      rolled my 9 properties into 7 :) (see if you can find the roll-up :)

      Now it's not required that you achieve the 7 properties, but that
      would be a good thing. Also, those aren't "conventions we agree to
      follow", so in that sense, Crystal Clear is not a methodology in any
      sense that we've discussed so far. I don't even know why someone
      would refer to it as a "methodology", except that people throw that
      word around for anything with a brand name these days.

      (Relevant aside: So why do I name it at all? Answer: So that people
      can refer to it. The first methodology I wrote, for IBM Consulting
      Group back in 1992, never got a name, so no one ever knew it existed –
      not even in IBM! Consequently, I use the word Crystal to mean "Stuff
      Alistair thinks he's learned" (with some subsetting, but I'm not sure
      which subsetting ... I try to leave project strategies out of
      Crystal. In any case, when you say "Crystal" you really are saying,
      in some sense "Stuff Alistair thinks he's learned". Think about it.).

      Now, finally, back to one of your original questions. What's all this
      got to do with what makes projects work.?

      Back in 1991, when I was asked by my boss to write a methodology, I
      grabbed all the self-proclaimed "OO methodology" books out there, and
      told my boss, "They're all different and I don't know what's
      important." She told me to go interview / debrief project teams and
      find out, and gave me unlimited airline tickets to do so.

      The result was pretty close to what you ask for: "> ... carefully-
      conducted studies of how teams actually work, the > gain would be
      enormous."

      The outcome of these studies was my "Surviving OO Projects" book,
      which contains summaries of a bunch of projects, what I learned from
      them, and how to use them to understand projects. I'll place a wager
      you've never read the book, but it contains what your looking for, at
      least to the extent that one author and 5 years can produce. A second
      book to read is "Sustainable Software Development". You would also
      want to look at Barry Boehm's writings and Capers Jones', because
      they list project success/ failure factors in order of importance.

      These are all are methodology-neutral and focused on project and
      organizational success.

      The next outcome of these studies, particularly as connected to
      methodologies, was the 1999 paper "People as Spontaneous, Non-linear
      components in Software development."
      (http://alistair.cockburn.us/index.php/Characterizing_people_as_non-
      linear%2C_first-order_components_in_software_development,
      http://tinyurl.com/gyeqz ).

      Finally, my Dr Philos thesis talks a bit about the relation between
      the two (see
      http://alistair.cockburn.us/index.php/People_and_methodologies_in_soft
      ware_development, or http://tinyurl.com/ytqoov).

      Summarizing,

      Instantiated methodologies are one-off, even transient with about a 3-
      month half-life.

      The specific "methodology" might account for some non-negligible
      portion of project- or organizational success (I'd give it 5% - 15%
      with today's brain waves). Barry Boehm and Capers Jones list the
      stuff that's ahead of it – experience project manager and senior
      designers topping the list, if I recall.

      When you go to grab a methodology, look first to
      * common language and
      * team conventions.

      When you go to "published methodology", look to
      * broad brush strokes of our team's conventions, and
      * interesting techniques to consider

      And never forget that
      * People trump processes
      * Politics trumps people

      Does that help at all?

      Alistair
    • aacockburn
      ... time. ... Nice questions ... Most of what I know about Methodologies I learned when I joined the IBM Consulting Group in 1991 – it was chock full of
      Message 89 of 89 , Mar 1 1:39 PM
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, "Charlie Poole" <xp@...>
        wrote:
        >
        > I haven't cared about specific (named) methodologies for a long
        time.
        > So I asked myself, who does care?
        >
        > ... carefully-conducted studies of how teams actually work, the
        > gain would be enormous.
        >
        > Now a methodologist might pop in here and say that's what we
        > do - or try to do - and you, Charlie, are simply expressing a
        > very common misconception about the study of methodologies.
        > Should there be such a person on the list, my answering
        > question would be "How come this misconception exists?"
        >
        > Charlie
        >

        Nice questions ... Most of what I know about "Methodologies" I
        learned when I joined the IBM Consulting Group in 1991 – it was chock
        full of card-carrying methodologists – in fact that was the entire
        purpose of our group. I'll tell you what /they/ said back then (to
        the extent I can recall back that far).

        Also, I'll say what the Scandinavian school of methodologists (super
        star example is Lars Mathiassen who got 2 doctorates in software
        development methodology! He was one of my coaches for my Dr. Philos.
        thesis). Also, I'll describe what I did in terms of those studies
        you refer to and how that interacts with the topic of methodologies
        (this was actually the topic for my Dr. Philos thesis, see it online
        on my web site).

        However, first, the word methodology has oodles of slightly different
        meanings, and the value of each is slightly different.

        Lars Mathiassen and co. use the word "method" instead
        of "methodology", and the connotation is slightly different. "Method"
        is something like "technique". Lars and co. like to say that a method
        is like a ladder that you use to climb up to a higher platform – once
        you're up there, you no longer need the ladder and can discard it.

        TDD is a "method", CRC is a "method", the "Rumbaugh modeling
        technique" is a method, and so on. Once you learn and internalize
        them, you don't notice or care if you are using them. (This is the
        Shu-Ha-Ri progression, see <link>).

        This is what I believe you are referring to when you write: "I
        realize I haven't cared about specific (named) methodologies for a
        long time."

        That's all fine, but that's really taking about techniques. Jeff
        Patton writes, "I have a bunch of tricks I use, and then someone asks
        me to teach them to him/her, and suddenly I have to come up with a
        Shu-level description for a trick ... and then it gets a name, and
        people start to copy it and quote it and ... And all it ever was was
        a trick I used on occasion."

        This is a useful way to look at methods or techniques. And here you
        are correct to "Learn it and Leave it".

        But what about "methodologies"?

        A methodology is (for one view of the term) a coordinated set of
        methods and techniques. That is, it's a macro-method.

        In this sense, all the stuff about "Learn it and Leave it" apply.
        That would be baseline XP, baseline Scrum, baseline DSDM, baseline
        FDD. Baseline Crystal Clear, too, although I designed that one to
        potentially cross the next boundary.

        However, the macro-method thing has a particular advantage, the one
        touted by the methodology experts in the IBM Consulting Group – it
        sets up a vocabulary that can be taught to and shared by everyone
        involved.

        Scrum is hitting this point these days – a very-large-company guy
        told me, "What's nice about Scrum is that we can bring people
        together from all over the world, and they know what a backlog is, a
        daily stand-up, a sprint, etc, so they can just started working
        together." Someone joining the group would ask, "How long is your
        sprint? When do you do your daily stand-up? What constitutes 'done'?"
        and then they're off and running.

        The next, and my favorite view of "methodology" is "the set of
        conventions the people agree to follow." I like this because it is
        easy to understand, easy to document, it naturally captures the drift
        of conventions over time, and you will never outgrow it.

        You can't "Learn and Leave" your group's conventions – they're alive
        and always in play – they're a social construction that you must
        attend to daily / weekly / whenever.

        This definition meshes nicely with the macro-method, in the following
        sense... My old boss at the IBM Consulting Group told me, "When you
        place an ad in the paper for a new person, what you write in the ad
        is an artifact of your methodology." That is, you write, "Someone
        with Scrum / XP / Modeling / Agile PM / Ruby / <whatever> skills",
        and when that person shows up you say, "You'll be sitting here,
        working with these people, taking information from those people,
        giving things to those other people, etc.".

        All of that is the /result/ of your set of conventions (possibly your
        macro-method, depending on how tight you rmacro-method is).

        I hope you are registering at this point that outside of Andersen
        Consulting's old Method One, we have left "named methodologies" long
        ago. We're in the unnamed space, the "here's what we do, it doesn't
        really have a name." XP isn't sufficient to cover this space, Scrum
        isn't, even DSDM isn't. The set of conventions we/you follow is far
        richer, more detailed and more specific than can be written down by
        any but the largest, centrally organized and probably DoD
        organization.

        When you play in this "set of conventions" space, then a new topic
        arises for named, published methodologies: What subset of the total
        set of conventions does it cover?

        XP1e, for example, named quite a lot of stuff. XP2e names more, if
        you choose to use them all. But there's still lots of stuff left out
        that you need to take care of (code formatting conventions? test
        naming conventions? Exactly when you do stand-ups and reflections?)

        As a result, when I write "a methodology is the set of conventions
        the team agrees to follow", this is the transient, just-for-this-
        iteration, never-written-down-but-still-understood, one-off,
        transient methodology --- I'll call this an instantiated methodology.

        Then there's the published thing – a chosen set of conventions that
        might apply over multiple iterations, multiple teams, maybe even
        multiple projects. Those are the "brand" methodologies that Ron keeps
        trying to quash.

        Knowing all that, I wrote Crystal ... what the heck is that?

        First, I asked myself what subset of conventions might possibly be
        reusable across teams ... and I got, basically, the empty set.

        So I asked myself "What is important?" and I came up with some
        principles, some theories, some graphs of "this-trades-off-with-
        that". Those are Crystal.

        When I went to Crystal Clear, I started from the most important set
        of patterns that I felt could pass the cross-project-conventions
        test, exactly as has been discussed in this thread. I came up with 13
        that might be reusable ... but the word "pattern" turns out to be a
        synonym for two, possibly different things: properties, and
        strategies.

        When I examined the 13 patterns I was inclined to stuff into Crystal,
        I found 9 properties and 4 strategies. Since I think that strategies
        are project- and situation-specific, I removed those and put them
        into the Strategies chapter. I paid attention to Steven Covey and
        rolled my 9 properties into 7 :) (see if you can find the roll-up :)

        Now it's not required that you achieve the 7 properties, but that
        would be a good thing. Also, those aren't "conventions we agree to
        follow", so in that sense, Crystal Clear is not a methodology in any
        sense that we've discussed so far. I don't even know why someone
        would refer to it as a "methodology", except that people throw that
        word around for anything with a brand name these days.

        (Relevant aside: So why do I name it at all? Answer: So that people
        can refer to it. The first methodology I wrote, for IBM Consulting
        Group back in 1992, never got a name, so no one ever knew it existed –
        not even in IBM! Consequently, I use the word Crystal to mean "Stuff
        Alistair thinks he's learned" (with some subsetting, but I'm not sure
        which subsetting ... I try to leave project strategies out of
        Crystal. In any case, when you say "Crystal" you really are saying,
        in some sense "Stuff Alistair thinks he's learned". Think about it.).

        Now, finally, back to one of your original questions. What's all this
        got to do with what makes projects work.?

        Back in 1991, when I was asked by my boss to write a methodology, I
        grabbed all the self-proclaimed "OO methodology" books out there, and
        told my boss, "They're all different and I don't know what's
        important." She told me to go interview / debrief project teams and
        find out, and gave me unlimited airline tickets to do so.

        The result was pretty close to what you ask for: "> ... carefully-
        conducted studies of how teams actually work, the > gain would be
        enormous."

        The outcome of these studies was my "Surviving OO Projects" book,
        which contains summaries of a bunch of projects, what I learned from
        them, and how to use them to understand projects. I'll place a wager
        you've never read the book, but it contains what your looking for, at
        least to the extent that one author and 5 years can produce. A second
        book to read is "Sustainable Software Development". You would also
        want to look at Barry Boehm's writings and Capers Jones', because
        they list project success/ failure factors in order of importance.

        These are all are methodology-neutral and focused on project and
        organizational success.

        The next outcome of these studies, particularly as connected to
        methodologies, was the 1999 paper "People as Spontaneous, Non-linear
        components in Software development."
        (http://alistair.cockburn.us/index.php/Characterizing_people_as_non-
        linear%2C_first-order_components_in_software_development,
        http://tinyurl.com/gyeqz ).

        Finally, my Dr Philos thesis talks a bit about the relation between
        the two (see
        http://alistair.cockburn.us/index.php/People_and_methodologies_in_soft
        ware_development, or http://tinyurl.com/ytqoov).

        Summarizing,

        Instantiated methodologies are one-off, even transient with about a 3-
        month half-life.

        The specific "methodology" might account for some non-negligible
        portion of project- or organizational success (I'd give it 5% - 15%
        with today's brain waves). Barry Boehm and Capers Jones list the
        stuff that's ahead of it – experience project manager and senior
        designers topping the list, if I recall.

        When you go to grab a methodology, look first to
        * common language and
        * team conventions.

        When you go to "published methodology", look to
        * broad brush strokes of our team's conventions, and
        * interesting techniques to consider

        And never forget that
        * People trump processes
        * Politics trumps people

        Does that help at all?

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