Podría decirse que el aspecto más importante de la agilidad es el cambio. De hecho, la agilidad puede entenderse como pasar de una forma de trabajar a otra. De hacer algo planificado que es potencialmente inútil, a hacer algo inesperado pero seguramente útil.

Para lograr el cambio, primero hay que descubrir qué se puede hacer de forma diferente en la próxima acción. Descubrir el cambio necesario suele ser doloroso. Las personas están acostumbradas a hacer las cosas de una manera específica. Están acostumbradas a realizar tareas concretas, bien conocidas. Sacarles de su rutina diaria es incómodo y muchas veces puede encontrar resistencia. Esto es normal, incluso si se está preparado para el cambio.

Hemos llegado a valorar más [...] responder al cambio que seguir un plan.
- El Manifiesto Ágil

El cambio puede tener diferentes orígenes. Probablemente la más dolorosa sea cuando un cliente te dice que tu producto no hace lo que él/ella quiere. Hay que analizar las quejas de los clientes y, si son razonables, considerar su inclusión en el producto. Estos cambios pueden tener un gran impacto tanto en el producto como en el flujo de trabajo de desarrollo.

Otro posible cambio inesperado es cuando se nos escapan uno o dos fallos y acaban apareciendo en el producto lanzado. El cliente vendrá y se quejará de que el producto funciona de forma defectuosa. Este tipo de queja es, sin embargo, menos dolorosa que la anterior. Sí, hay un error que hay que arreglar, pero al menos tanto el cliente como tú estáis de acuerdo en lo que debe hacer el producto. Así que el cambio afecta al flujo de trabajo del equipo de desarrollo al introducir una tarea imprevista, pero todo el mundo acepta sin problemas que hay que hacerlo.

La tercera forma de producir cambios en un proyecto o en nuestro flujo de trabajo de desarrollo puede producirse cuando uno o varios miembros del equipo identifican un problema. Entonces encuentran una solución e intentan introducir un cambio en el flujo de trabajo de todo el equipo. Este cambio nace para eliminar el problema identificado. Este tipo de cambio requiere que una persona convenza a todos los demás de que existe un problema. Además, esta persona debe convencer a los demás de que las molestias causadas hoy por el cambio facilitarán la vida de todos mañana. Este puede ser el cambio más difícil de introducir, independientemente del lado de la barricada en el que te encuentres.

Lea el resto de la serie "Entre bastidores":

Entre bastidores #9: La herramienta adecuada para el trabajo - Desarrollo de múltiples idiomas

Entre bastidores #8: Programador políglota - Desarrollo multilingüe

Entre bastidores #7: Ser ágil respondiendo al cambio

Entre bastidores #6: El arte de programar

Entre bastidores #5: Doble visión - Programación en parejas

Entre bastidores #4: Tecnología ágil

Entre bastidores #3: Choque cultural

Entre bastidores #2: No somos prodigios

Entre bastidores #1: Cómo desarrollamos el sistema operativo de almacenamiento