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

Ship has sailed?

Expand Messages
  • Cory Foy
    For Agile 2008, I had submitted a talk about helping people new to agile practices understand the variety of agile practices out there - Scrum, XP, TDD,
    Message 1 of 89 , Feb 27 6:06 PM
    • 0 Attachment
      For Agile 2008, I had submitted a talk about helping people new to agile
      practices understand the variety of agile practices out there - Scrum,
      XP, TDD, Crystal, FDD, etc. I ended up with a comment that said:

      "I think Bob Martin is right: the industry has decided that Agile ==
      Scrum plus some XP practices. In the changed zeitgeist, talks which look
      at underpinnings are going to be more popular than compare-and-contrast
      talks." It was titled, "This ship may have sailed".

      This was fascinating to me, as I'm sure other people would have a
      different interpretation (Lean, Crystal). But, if the above is true,
      then maybe we just need to do away with all of the methodologies and
      just endorse agile practices - in other words, move from a structured
      approach to more of a patterns-based approach.

      Since the review system isn't the best place to get feedback, I wanted
      to hear what other people thought. Have agile practices matured to the
      point where there is no need for the overarching categories? If not, is
      it important for people to be able to understand the differences in
      methodologies?

      --
      Cory Foy
      http://www.cornetdesign.com
    • 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, 2008
      • 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.