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

Re: [XP] Who cares about methodologies?

Expand Messages
  • Daniel Pupek
    I like to think that all the methodologies give us a language for discussing what we do. For shops that are really dysfunctional, strict adherence to a
    Message 1 of 89 , Feb 29, 2008
      I like to think that all the methodologies give us a language for
      discussing what we do.

      For shops that are really dysfunctional, strict adherence to a
      particular methodology can serve as a kind of "boot camp". "Boot
      camp" breaks things down to a mechanical level. Once the mechanics
      have been learned the team can begin to do what most "functional"
      teams do, develop good software. Eventually they become self
      organizing and over time they start to develop their own "language"
      for discussing what they do.

      A lot of shops do this naturally and never need the "boot camp" stage.
      They develop their own methodology or a per project methodology. I
      like to think that we wouldn't have these discussions if universities
      would teach a more pragmatic approach to software development.

      On Sat, Mar 1, 2008 at 4:25 AM, Cory Foy <usergroup@...> wrote:
      > Charlie Poole wrote:
      > > Methodologists - those who make a study of methodologies - obviously
      > > have to care. Their caring is somewhat circular, since they wouldn't
      > > be methodologists if they gave up on it.
      > >
      > > People who are benefiting from the success of a particular methodology
      > > obviously also care, since they want their methodology to gain a larger
      > > mind- or market-share.
      > >
      > > Folks who want to substitute easy labels for understanding care quite
      > > a bit. There are many such people, but I don't much care about them,
      > > so I'm passing them by.
      > I think there is a fourth category - people who are trying to figure out
      > how to be more agile in their development, and don't have the luxury of
      > bringing on a consultant.
      > In other words, beginners care, because they are looking not to dissect
      > the practices, but for someone to go, "Go do". I talk about it a bit
      > here: http://www.cornetdesign.com/2006/03/dreyfus-model-experiment.html
      > I think the reason it doesn't matter to you is that you have the
      > understanding and context to be able to apply the practices that fit in
      > the right situation. But people just coming into this don't. It's like
      > someone coming into development, and asking how to be a good developer.
      > If we just throw the GoF book at them, they will read it, but have a
      > hard time figuring out how to apply it. But, if we instead say, "Since
      > you are building a web app, start with using the Model-View Presenter
      > pattern to understand concepts like separation of concerns". I like this
      > because then they have a concrete implementation (MVP) they can try.
      > Does that mean they should apply MVP to everything? Of course not. They
      > need to keep learning and growing and finding out about other patterns,
      > and trying new things.
      > So I think named practices are a good starting point for getting people
      > to focus while they are learning and understanding. As they grow from
      > that, the names will become less and less relevant. But that doesn't
      > mean they are any less important - after all, someone else is going to
      > have to learn this too.
      > --
      > Cory Foy
      > http://www.cornetdesign.com


      Checkout my blog @ http://blog.agilejedi.com
      Checkout my homepage @ http://www.agilejedi.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
        --- In extremeprogramming@yahoogroups.com, "Charlie Poole" <xp@...>
        > I haven't cared about specific (named) methodologies for a long
        > 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

        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

        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

        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

        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://tinyurl.com/gyeqz ).

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


        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?

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