No todo es agile. La flexibilidad está en que esta metodología conviva con la convencional

Eduardo Méndez Polo    12 noviembre, 2019
no-todo-es-agile

¿Qué es agile?, preguntas mientras clavas en mi pupila tu pupila azul. ¿Que es agile? Agile eres tú.

Si el pobre Bécquer levantara la cabeza me daría un sopapo por pervertir su poema de una forma tan rastrera. Pero esta broma me sirve para ilustrar la indefinición del término agile, que puede resultar muy difuso si no tenemos cuidado. Aunque en este momento pueda parecer lo contrario, no todo es agile. Carmen Lasa daba las claves recientemente en este mismo blog.

Yo hoy trataré de explicarlo, en mi línea, con “una de vaqueros”. En “El oro de Mackenna” (J. Lee Thompson, 1969) Gregory Peck forma parte de una expedición a través de territorio indio para encontrar un lugar en el que la leyenda cuenta que hay oro abundante. Va rodeado de forajidos y buscadores de fortuna. Los indios, por su parte, consideran que es territorio sagrado, por lo que no les hace demasiada gracia que estos individuos campen por allí.

Con solo ver quiénes forman la partida, ya se advierte desde el principio que la cosa no puede salir bien… En el grupo cada uno tiene su propio interés, sus propias intenciones y persigue sus propios objetivos. Las capacidades son muy dispares aunque, eso sí, todos tienen una avaricia semejante.

Falta de concreción en torno a agile

Con agile, desgraciadamente, ocurre un poco lo mismo. Existen certificaciones de metodologías concretas, con lo que practicas o no esa metodología pero con frecuencia ocurre que prácticamente cualquiera puede aplicar el adjetivo agile a su proyecto sin el menor reparo ni fundamento. Y no todo es agile: ni lo es todo lo que se denomina así ni esta metodología es la más adecuada siempre.

Es cierto que el Manifiesto agile definió el concepto en forma de cuatro valores y doce principios. Pero no hubo un trabajo posterior de concreción. De hecho, si repasamos esos cuatro valores nos sirven para el programa de cualquier “gurú del buenismo” en el entorno profesional:

  • Individuos e interacciones por encima de procesos y herramientas.
  • Software en marcha sobre documentación extensiva.
  • Colaboración con el cliente más allá de la negociación contractual.
  • Respuesta ante el cambio antes que seguir un plan.

Se echa en falta cómo llevarlos a cabo.

En el mundo de las Tecnologías de la Información nos encontramos con cierta frecuencia con proyectos que incluyen, por ejemplo, despliegues de infraestructura física o la instalación de productos software. En dichos casos poco hay que agilizar (no todo es agile):

  • No se pueden descomponer estas actividades en partes pequeñas
  • No se puede trabajar para resolverlas en equipos multidisciplinares
  • No se pueden definir ciclos cortos
  • Ni están sujetos a una indefinición en el resultado que permita adaptarse a cambios en los requisitos.

La metodología adecuada en cada caso

Pero si nuestras organizaciones están impulsando la adopción de modelos de trabajo agile como Scrum, DevOps, Kanban, Lean, Design Sprint, etc. ,¿quien es el valiente que le dice al jefe que no todo es agile, que esta metodología no es la más adecuada para el resultado perseguido?

En esos momentos es cuando el arquitecto o el jefe de proyecto adquiere la verdadera importancia de su rol y  debe asumir esta responsabilidad. Le corresponde extraer dichas actividades que, por la rigidez de sus etapas y metas, necesitan ser gestionadas con una metodología convencional en un subproyecto aparte y organizar el proyecto global de manera que se eviten o minimicen las dependencias entre las fases agile y las convencionales.

A este respecto, Gartner Group mantiene desde hace años una línea de trabajo muy interesante, a la que denomina IT Bimodal, que defiende precisamente esta dualidad. Y propone cómo debe resolverse tanto la organización de las empresas que decidan adoptarla, como el seguimiento que permita valorar el éxito en su implementación y tomar decisiones estratégicas respecto a cómo avanzar en la transformación.

Volviendo a la película, la pandilla que debe guiar McKenna por el territorio indio no termina bien, como era de esperar. Pero es lógico. Por una parte, porque no hay una definición de expectativas y objetivos comunes. No acometen “el proyecto” en diferentes actividades que puedan realizarse en paralelo empleando diferentes metodologías. Y, en segundo lugar, porque se trata de una película del oeste, y si todos terminaran felices y en paz, no tendría ninguna gracia.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *