The Self-Adaptive Process
So far I've talked about adaptivity in the context of a project adapting its software frequently to meet the changing requirements of its customers. However there's another angle to adaptivity: that of the process changing over time. A project that begins using an adaptive process won't have the same process a year later. Over time, the team will find what works for them, and alter the process to fit.
The first part of self-adaptivity is regular reviews of the process. Usually you do these with every iteration. At the end of each iteration, have a short meeting and ask yourself the following questions (culled from Norm Kerth)
What did we do well?
What have we learned?
What can we do better?
What puzzles us?
These questions will lead you to ideas to change the process for the next iteration. In this way a process that starts off with problems can improve as the project goes on, adapting better to the team that uses it.
If self-adaptivity occurs within a project, it's even more marked across an organization. To deepen the process of self-adaptivity I suggest teams do a more formal review and major project milestones following the project retrospective sessions outlined by Norm Kerth. These retrospectives involve a 2-3 day offsite meeting and a trained facilitator. Not only do they provide learning for the team, they also provide learning for the whole organization.
A consequence of self-adaptivity is that you should never expect to find a single corporate methodology. Instead each team should not just choose their own process, but should also actively tune their process as they proceed with the project. While both published processes and the experience of other projects can act as an inspiration and a baseline, the developers professional responsibility is to adapt the process to the task at hand.
This self-adaptivity is most marked in ASD and Crystal. XP's rigid rules seem to disallow it, but that is only a surface impression since XP does encourage people to tune the process. The main difference with XP is that its advocates suggest doing XP by the book for several iterations before adapting it. In addition reviews are neither emphasized, nor part of the process, although there are suggestions that reviews should be made one of the XP practices.
The Methodologies
Several methodologies fit under this agile banner. While all of them share many characteristics, there are also some significant differences. I can't highlight all the points in this brief survey, but at least I can point you to some places to look. I also can't speak with significant experience about most of these. I've done quite a lot of work based on XP, and seen RUP around in many guises, but with most of the others my knowledge is primarily the less adequate book knowledge.
