Hasta ahora he hablado sobre la adaptabilidad en el contexto de un proyecto adaptando frecuentemente su software para enfrentarse a los requisitos cambiantes de sus clientes. No obstante hay otro �ngulo de la adaptabilidad: el del proceso que cambia con el tiempo. Un proyecto que empieza usando un proceso adaptable no tendr� el mismo proceso un a�o despu�s. Con el tiempo, el equipo encontrar� lo que funciona mejor para ellos, y alterar� el proceso a su medida.
La primera parte de la auto adaptabilidad son las revisiones regulares del proceso. Normalmente se hacen con cada iteraci�n. Al final de cada iteraci�n, haga una reuni�n corta y h�gase las siguientes preguntas (escogidas de Norm Kerth)
- �Qu� hicimos bien?
- �Qu� hemos aprendido?
- �Qu� podemos hacer mejor?
- �Qu� es lo que nos confunde?
Estas preguntas traer�n ideas para cambiar el proceso en la siguiente iteraci�n. De esta manera un proceso que empieza con problemas puede mejorar conforme el proyecto avanza, adapt�ndose mejor al equipo que lo usa.
Si la auto adaptabilidad ocurre dentro de un proyecto, es aun m�s marcada en una organizaci�n. Para ahondar el proceso de la auto adaptabilidad sugiero que los equipos hagan una revisi�n m�s formal e hitos del proyecto mayores siguiendo las sesiones retrospectivas del proyecto esbozadas por Norm Kerth. Estas retrospectivas involucran reuniones de 2-3 d�as y un facilitador entrenado. Ellas no solo dan aprendizaje al equipo, tambi�n dan aprendizaje a la organizaci�n entera.
Una consecuencia de la auto adaptabilidad es que nunca se debe esperar encontrar una metodolog�a corporativa �nica. En cambio cada equipo debe no simplemente escoger su propio proceso, debe tambi�n afinar activamente su proceso conforme avanza el proyecto. Mientras que tanto los procesos publicados como la experiencia de otros proyectos pueden actuar como una inspiraci�n y una l�nea de fondo, la responsabilidad profesional de los desarrolladores es adaptar el proceso a la tarea en mano.
Esta auto adaptabilidad es muy marcada en ASD y Cristal. Las reglas r�gidas de la XP parecen desaprobarla, pero �sa es s�lo una impresi�n superficial ya que la XP anima a la gente a afinar el proceso. La diferencia principal de la XP es que sus promotores sugieren hacer XP al pie de la letra por varias iteraciones antes de adaptarlo. Adem�s las revisiones no son enfatizadas, ni parte del proceso, aunque hay sugerencias de que las revisiones deber�an ser una de las pr�cticas de la XP.