XProgramming
>
XP Magazine
>
Integrating Agile Methods
COLLECTED TOPICS: Adventures in C# |
Documentation in XP | Book Reviews
Integrating Agile Methods
02/23/2006
Today on the CrystalClear list, Ernest Mnkandla said, in part:
What I have found is that agile methodologies can be safely grouped as follows:
- Technical issues (XP, Catalyst)
- Project Management (LD, Scrum, DSDM)
- Modeling (FDD, AMDD, ICONIX)
- Agile development philosophy (Crystal, ASD)
As a ten-year practitioner and advocate of Agile methods, I do not find this grouping terribly satisfactory. Here are some reasons why:
- XP contains at least as much actual project management content as Scrum: XP's project management is very Scrum-like, though it reportedly comes from another source, with the addition of specific project planning and reporting practices. This makes me question its classification as "technical" rather than "project management".
- Scrum teams find themselves performing better when they add technical practices to the mix. Some Scrum advocates are now saying that those practices have been in Scrum "all the time". This makes me question limiting Scrum's class to "project management".
- As I see it, Crystal differs from other methods primarily because of Alistair's chosen style of appearing not to tell people what to do, where many other methods do appear to tell people what to do. Neither appearance is quite accurate: Alistair makes clear what he thinks are good practices, and I'm aware of no method that is really defined by what one MUST / MUST NOT do. (Some do have a strong focus on specific practices, but I see that much more as a matter of author style than as a defining differentiation.)
- Alistair's /Agile Software Development/ and other works do seem to me to be more "philosophical" than some other books, but at the same time /Extreme Programming Explained/ second edition is more along those lines as well. Similarly, much of my web-published work has been focused on determining how and why these things work, and how to think about them.
I could go on. I see much commonality among the Agile methods, and I think there would be more were there not so much advantage -- or perceived advantage -- to having a brand of one's own. It would also be helpful if a few of us egomaniacs populating the upper tiers of the Agile thought space were able to follow our own dictates and communicate effectively with each other.
In any case, I personally would prefer an approach to the methods that, rather than classifying them into separate groups as shown above, would work to highlight the commonalities, the insignificant differences, and to explore what, if any, essential differences there are in these people's ideas.