Agile is not XP

I recently heard this podcast with Dave Thomas. Dave has talked on many occasions about the Dreyfus model of Skill Acquisition, which is similar to Shu Ha Ri. He also talks in the podcast about some Agile practitioners being dogmatic in their views. So in a sense, listening to the padcast made me go and write these posts, something that I've been meaning to do for a long time anyway.

In a previous post I had said "Sometimes I think that the term Agile has been co-opted by the XP and Scrum groups, but that's a topic for another post."

What is agile development? In theory, agile processes follow the four points of the agile manifesto. However, most people use the term "agile" to actually refer to either XP or Scrum, and consequently practices from these processes are invariably attached to the term "agile". This is a pity, because agile is a general term that refers to a host of different methodologies, many of which differ very markedly from XP.

For instance, while XP says no big design up front, both FDD and DSDM have distinct modelling phases at the start of a project. Similarly, XP minimises documentation, whereas say Crystal Clear does emphasise certain documentation. This obviously irritates a lot of people. Alsitair has an AgileIsntXp page on his twiki.

I also agree with Dave's comment that agilists can sometimes be dogmatic. How many times have we seen arguments along the lines of "thats big design up front, so its not agile", never mind if it helped solve the problem or not. I was just searching around for more info on the No Fluff Just Stuff conference when I came across this link which just illustrates the point (see section on Pragmatic Tracer Bullets).

If you are having a big discussion on the level of "is this big design up front or not?" then it's a lost cause already, because that is the wrong question. The question should be "will it help me produce working software?" and if the answer is yes, then you do it. Of course, as we saw in the Shu Ha Ri post, beginners who are just starting out with the process need clear rules, and "no big design up front" is a clear rule, whereas "will it help me produce working software" is not so easy to answer. You need to be in the Ha or Ri phase to answer this one.

There is a fundamental paradox here, because agile was developed in response to the "rules" based ISO/CMMI processes, replacing them with a more intuitive understanding of project management as placed out in the agile manifesto. This is great for the intermediate and expert project managers, what about those just starting out on the process who need clear rules? We need to put in certain rules and best practices to help beginners. But in the end, guiding beginners is all the rules are for. They are not "best practices" to be followed by everyone in every situation.

Finally, go read James Bach's posts on What is agile methodology? and No Best Practices, both of which hit the nail squarely on the head.

This post is a part of the selected archive.