More on Extreme Programming



  • I went to Visual Studio Connections last week, and Nick Landry popped this little gem of a quote off, and I just had to share, given the recent Agile/XP discussion:

    "I always say that Extreme Programming is 'giving a name to a lack of method'".

    -- Nick Landry



  • Planning means to replace random by mistake.



    (German: Planung bedeutet, Zufall durch Irrtum zu ersetzen)



  • That's funny. Did you get that from an Agile book? To follow that logic, you cannot ever plan, because you cannot ever take into account the unknown. Pretty much sums up Agile logic: don't plan, just do. Alex was right, that's 100% cowboy coding.



  • @Whiskey Tango Foxtrot Over said:

    That's funny. Did you get
    that from an Agile book? To follow that logic, you cannot ever plan,
    because you cannot ever take into account the unknown. Pretty much sums
    up Agile logic: don't plan, just do. Alex was right, that's 100% cowboy
    coding.





    This saying is quite common in German, I can't say who said it first. I
    read it in a busines magacine. But don't get me wrong, I don't want to
    revive that agile vs. whatever discussion. If you think it doesn't work

    • you are surely right, even if it is only because this is a
      self-fullfilling prophecy.


  • @ammoQ said:

    magacine


    Hey man.

    Just because the Z is often TZ in German doesn't mean you can freely use the [i]tsee[/i] in its place. :)



  • Whiskey,



    It's a cute comment, and would be funnier if it held a grain of truth.
    After all this time, a lot of people still think there's no planning
    and no engineering rigor in XP or other agile methods. Oh, well.



    I've seen many examples of teams who say they're using XP, when in fact
    they're just making a half-assed stab at TDD or pair programming out of
    context. Quite the opposite of casual or unplanned cowboy coding, XP
    requires such a high level of professional discipline that it takes a
    conscious effort to maintain the intensity day after day. The 12
    practices complement each other in such a way that if you do it right
    you'll get excellent results, but if you do it wrong you'll fail
    spectacularly - probably worse than with traditional methods, which
    have sort of a built-in safety net of administrative procedures.



    At our company we have built a small but successful internal agile
    practice. Initially we tried to adopt XP fully. We got it right on a
    few small projects, but ultimately we came up with a hybrid methodology
    that includes some XP practices but is a little less demanding on
    developers. It isn't as effective as full-bore XP, but it's a lot more
    accessible to the average developer. Reality, as it so often does,
    intrudes rudely on a beautiful theory.



    As far as agile planning is concerned, you might find this article by
    an agile consultant interesting. She briefly goes over the five levels
    of planning the agile approach requires in order to be successful. I
    haven't yet figured out how to make a link work on this site, so I'll
    just put the url in as text. (My bad.)



    http://theagileblog.net/2006/04/gimme_five_the_five_levels_of_1.html



    Of course, you will only be interested in that if you're open minded
    about the agile approach. Those who are still at the level of dogma and
    who enjoy snappy little quotes might prefer another blog entry, in
    which the author convincingly destroys XP with unassailable logic, and
    in the process proves that a solid, logical argument can be built from
    an invalid premise.



    http://weblog.burningbird.net/2006/04/13/technology-is-already-extreme



    I hope you enjoy both pieces!




  • @Dave Nicolette said:

    [ XP is ] a beautiful theory.


    If only we were all robots, eh?

    BurningBird seems to equate XP with Agile. You say there are [i]several[/i] Agile methods? The Agile blog describes the planning method required for Agile. Incidentally, it's the planning method required for ALL large projects.

    I found both articles pretty silly. Lots of meta-talk and not enough real information.

    I'd like to know, once and for all, and in no more than 4 short- to medium-length sentences, what you think agile really is. Give it to me short and simple. We can always work out the details later.

    PS.
    You can make a link by going into HTML mode, and writing the HTML yourself. Unless you're posting with Opera. Then you're on your own.

    Now [i]that's[/i] practical info. :)



  • @dhromed said:

    @ammoQ said:
    magacine


    Hey man.

    Just because the Z is often TZ in German doesn't mean you can freely use the [i]tsee[/i] in its place. :)




    You are so right... the real WTF is that I looked up that word in the dictionary, but misspelled it anyway.



  • @ammoQ said:

    You are so right... the real WTF is that I looked up that word in the dictionary, but misspelled it anyway.

    [:D]

    (This forum needs a LOL smiley)



  • >If only we were all robots, eh?

    Aren't we? Some do seem to react to things in the way they've been programmed.

    >
    You can make a link by going into HTML mode, and writing the HTML yourself.

    Thanks. Maybe I should actually look at the available options once in a while.

    >
    I'd like to know, once and for all, and
    in no more than 4 short- to medium-length sentences, what you think
    agile really is. Give it to me short and simple. We can always work out
    the details later.

    Are you serious? The Agile Manifesto consists of a four-statement summary of the key concepts, and we (our whole industry) have been working out the details for the past five years. As for me, I think the most important statement in that manifesto is the first one. There's a lot of overlap across different processes and methodologies, especially those in the "lean" and "agile" camps, but I'd say that one point is the key differentiator.
    At the risk of exceeding the sentence limit you impose, I think it's a good idea to recognize that some of the things we're talking about are at different levels of detail. An approach (e.g., adaptive vs predictive) is a a high level of abstraction; it's more a question of mindset than detailed practices. A project management process (e.g., Scrum or CMMI) frames a project from end to end and keeps track of progress. At the lowest level of detail, a methodology (e.g., XP) specifies particular software engineering practices that people are supposed to follow in their day-to-day work. To compare "agile" with "XP" is a synecdoche.



  • >The Agile blog describes the planning
    method required for Agile. Incidentally, it's the planning method
    required for ALL large projects.

    Sorry I neglected to address this point earlier. It's true that this is the planning method required for all large projects. That's exactly the point. The implication of the original post and some of the follow-up comments has been that there is no planning at all in agile development.
    In that context, it was necessary to point out that agile methods don't excuse us from planning.

    The assertion is made by people who have never actually used agile methods. I would encourage you to consider that when assessing their comments.



  • @Dave Nicolette said:


    Are you serious? The Agile Manifesto consists of a four-statement summary of the key concepts, and we (our whole industry) have been working out the details for the past five years. As for me, I think the most important statement in that manifesto is the first one. There's a lot of overlap across different processes and methodologies, especially those in the "lean" and "agile" camps, but I'd say that one point is the key differentiator.

    So, "results" over "method" (or "ends" over "means"). Not so bad a goal.


Log in to reply