There seems to have been a recent increase in discussion around the definition of "agility" in a software development context. For example Brad Appleton has offered a definition of business agility. Business agility and software development agility seem to me like two different, although related, concepts but the post and comments are interesting.
Brad also blogged elsewhere on nutshell definitions of agile development where he included some related definitions from members of the Yahoo extreme programming group and a few other sources.
Today, I saw a blog post comparing software development styles to martial arts and philosophical schools. It was interesting to me because I’ve also been thinking of similarities between Jeet Kune Do and my own philosophy on software development. Some Bruce Lee quotes on Jeet June Do:
"I have not invented a "new style," composite, modified or otherwise that is set within distinct form as apart from "this" method or "that" method. On the contrary, I hope to free my followers from clinging to styles, patterns, or molds. Remember that Jeet Kune Do is merely a name used, a mirror in which to see "ourselves". . . Jeet Kune Do is not an organized institution that one can be a member of. Either you understand or you don’t, and that is that. "
"Learn the principle, abide by the principle, and dissolve the principle. In short, enter a mold without being caged in it. Obey the principle without being bound by it. LEARN, MASTER AND ACHIEVE!!!"
"A good JKD man does not oppose force or give way completely. He is pliable as a spring; he is the complement and not the opposition to his opponent’s strength. He has no technique; he makes his opponent’s technique his technique. He has no design; he makes opportunity his design.
One should not respond to circumstance with artificial and "wooden" prearrangement. Your action should be like the immediacy of a shadow adapting to its moving object. Your task is simply to complete the other half of the oneness spontaneously."
Notice that Lee is referring to mastering principles rather than techniques or practices. It appears to me that many XP "coaches" focus very strongly on techniques and practices and less on the principles that suggested those techniques. In some cases, I suspect the coaches themselves were primarily trained in technique and have a relatively limited understanding of the underyling principles.
Constrast the JKD philosophy to a recent call for an "An Extreme Stake in the Ground", where XP followers are urged to accept an "oath" to follow a relatively rigid set of techniques. Don’t get me wrong, these techniques are not particulary bad depending on the context, but the rigidity concerns me. To be fair, some of what appears to be rigidity couble be because of a focus on novice XP teams. When pressed, some of the XP leaders agree that more flexibility can be beneficial with an experienced team. As XP "crosses the chasm", there will be more and more experienced teams and I predict they will not be satisfied with rigid perspectives or being asked to tether themselves to a stake in the ground driven by someone not familiar with the team’s specific context.
I also just became aware of Pliant Software Development (PSD). It appears PSD is not exactly a movement yet, but I like the idea. According to their FAQ, "Pliant Software Development is a philosophy of software development based solely on doing what works and not doing what doesn’t work." They don’t provide specific techniques that work or don’t work. You are expected to discover that for yourself and the context you’re operating within.
It appears to me that PSD shifts the focus to becoming more aware of your context and improving your ability to assess what works and what doesn’t work in that context. It’s also good to remember that even the techniques for determining what works best should be pliant and context-dependent.
My own perspectives on software development are much more aligned with Agile/agile development than with waterfall/phasist techniques. Still, a pliant perspective will even support a waterfall process if that appears to be the best solution to to a specific context. I think that’s good. Whatever get’s the job done. The XP community has softened its claims a bit over the last few years, but it’s generally still a bit dogmatic for my tastes and produces too much propaganda. Nevertheless, I continue to believe the XP practices can offer much to those who are wise enough to learn to apply them well in their specific context.
I intend to post more on this topic in the future, but here are few more pointers to related discussions.