La liturgia ágil

En los cultos religiosos seguir las ceremonias y reglas a rajatabla es lo que se conoce como liturgia.

A menudo, estas normas de ejecución de los rituales persisten más allá del tiempo y la cultura, incluso cuando el contexto original que los creó ya no existe o es malinterpretado. Se convierten en un culto a la forma sobre el contenido, una adherencia reaccionaria a las prácticas aun cuando los valores fundacionales que las originaron hace tiempo que desaparecieron.

Esta tendencia se manifiesta en ciertas etapas de la evolución de una idea, típicamente en la fase de masificación, cuando la innovación se populariza y los principios que impulsaron el cambio de mentalidad quedan atrás.

El agilismo ya es tendencia y junto con ello viene la corrupción de los principios.

El peso abrumador de la metodología sobre la filosofía está creando situaciones cómicas a la vez que terribles: muchos equipos de desarrollo son forzados a seguir estrictamente una serie de prácticas que incomodan a todo el mundo y que a veces resultan contraproducentes.

Denomino este fenómeno Liturgia Ágil.

La corrupción del agilismo

A continuación vemos el gráfico del ciclo de vida de adopción de las innovaciones de Everett Rogers:

Los pioneros siempre tienen una mentalidad extrema dentro de su propio paradigma. Sus ideas emanan de la combinación de su genialidad como individuos, un contexto muy específico y probablemente mucha experiencia.

Los “primeros en adoptar” se reconocen inmediatamente a sí mismos en las ideas de estos pioneros y les siguen los pasos de cerca. Tienen una mentalidad similar y, en cierto modo, también son pioneros en su propio contexto ya que tienen que convencer a aquellos a su alrededor sobre algo nuevo y arriesgado.

Tanto los pioneros como los primeros en adoptar cometen muchos errores tratando de aprender a base de prueba y error sin embargo, como una sólida filosofía de fondo subyace a su momentum, son autocríticos y revisan constantemente sus procesos.

Si la genialidad de los pioneros combinada con la tracción añadida por los primeros en adoptar provocan que la innovación en cuestión salte la grieta (to cross the chasm), la mayoría se une al juego.

Un mercado de pioneros y “primeros en adoptar” es muy diferente al mercado popular:

• La mayoría de la masa no comparte la forma de pensar original y en realidad se sienten más atraídos hacia la moda que hacia la comprensión de la filosofía que subyace.
• Un potente nicho comercial aparece y junto con él, cursos, certificados y vendedores de elixires del oeste (también llamados coaches) hambrientos de tratos suculentos o lo que es peor, tratando de alimentar su ego y delirios de grandeza y guruismo.
• En muchos casos, ni siquiera las reglas litúrgicas son entendidas y emergen versiones pervertidas de los rituales adaptadas para ser más vendibles en ciertos entornos no tan ágiles.

La combinación de estos factores se degrada en la situación tragicómica que mencionábamos anteriormente: un grupo certificado de personas desmotivadas, metidos en una habitación con las paredes cubiertas de post-its, obligados a seguir un ritual vacío llamado stand-up, dolorosamente programando en pareja con alguien a quien odian y, en un momento dado… jugando a poker para estimar.

El paraíso ágil de nuestros sueños se fue trágicamente a pique.

¡Mira! El emperador no lleva ropa

No podemos ser ágiles sin gente ágil. Debemos esforzarnos por ser conscientes en todo momento y resistir la tendencia a dejarse llevar por la corriente. Tenemos que revisar nuestro proceso, como hicieron los pioneros, y preguntarnos a nosotros mismos: ¿están todos estos métodos y ceremonias aportando realmente el valor que se supone que deberían de aportar?

A modo de ejemplo y sin tratar de ser exhaustivo con esta lista:

La programación por parejas (pair programming) es una práctica excelente para promover la calidad de diseño y propagar el conocimiento. La intención de la programación por parejas va mucho más allá de sentarse juntos usando la misma computadora: requiere un propósito, una visión compartida y cierto know-how.

Cuando hacemos mal pairing solo porque “tenemos que pairear”, pagamos el costo sin obtener los beneficios y, en un momento dado, nos arriesgamos a frustrar a algunos programadores. No todas las combinaciones de dos personas funcionan y no todo el mundo puede o quiere pairear, lo cual está perfectamente bien.

No hay por qué pairear para ser agile. Se pueden hacer revisiones de código y sesiones de diseño para obtener un output similar (haciendo un gran énfasis en SIMILAR).

Los stand-ups ayudan mucho en la sincronización del equipo y la planificación a corto plazo, cuando se facilitan adecuadamente, los miembros están enfocados y la información compartida es relevante para todo el mundo.

Cuando se convierten en una rutina sin sentido el costo es enorme tanto en tiempo de trabajo como en libertad de movimiento del equipo. A menudo vemos los stand-ups convertidos en herramientas de gerencia para forzar a que todo el mundo se presente a una hora específica o como táctica de control. Esto es terrible.

No necesitas los stand-ups para ser ágil. Comunicación ad-hoc entre los miembros del equipo cuando sea necesario puede servir igualmente -o incluso mejor- para este propósito.

Las historias de usuario son muy útiles para capturar las necesidades de los usuarios, definir los límites del desarrollo y mantener al equipo enfocado en objetivos pequeños.

Las historias escritas pobremente son un mero trámite burocrático con el que tenemos que cumplir antes de poder ponernos manos a la obra. Además, nos arriesgamos a crear diseños concebidos de una manera estrecha en oposición al desarrollo de soluciones más amplias y bien pensadas.

A veces es mejor invertir en un diseño ligero up-front y bocetos del interfaz para definir las features en lugar de malgastar tiempo escribiendo historias triviales.

TDD… debo admitir que soy un poco dogmático sobre este tema. A no ser que estés haciendo un spike debes hacer TDD o sufrir el castigo que mereces por tus pecados!

Podría seguir enumerando y elaborando las perversiones de cada práctica ágil, pero creo que mi postura ya ha quedado suficientemente definida: si añade costo en lugar de reducirlo o entorpece el libre flujo de las personas, estamos haciendo las cosas mal.

Desprendiéndose de lo no-esencial

Bruce Lee es una gran fuente de inspiración para luchar contra la “corrupción”. Fue una persona que desafío los dogmas de su tiempo y apartó su arte (marcial) de los patrones fijos (liturgia) hacia un marco de flexibilidad y conciencia:

No consiste en aumentar cada día, sino en disminuir cada día. Despréndete de lo no-esencial

- Bruce Lee

Si buscamos la esencia nos topamos con el manifiesto ágil. En su primerísima línea dice

"Individuos e interacciones sobre procesos y herramientas"

Y un poco más adelante, en los doce principios el rol del equipo es enfatizado:

"Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo."

"Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados."

La gente es la clave para el éxito de todo proyecto. No importa qué modelo organizativo nos inventemos, si la gente no está comprometida no funcionará (como en política, pero dejémoslo para otro momento).

Motivación, compromiso, sentimiento de propiedad (ownership) y auto-organización son los valores sustanciales de una mentalidad ágil.

La principal preocupacion de los líderes de equipos ágiles debería de ser la moral del equipo. Si los miembros son buenos profesionales sabrán cómo solucionar cualquier problema si tienen la actitud adecuada. Si no son buenos profesionales... tenemos un problema mucho mayor que no se va a solucionar ni con técnicas agile ni con ninguna otra solución.

Añadir más proceso a un equipo disfuncional no va a ayudar en nada, solamente añadirá más caos al caos. La clave para el éxito es hacer más con menos: menos proceso, menos gente, menos reglas, menos tiempo para terminar el trabajo. Deja que la gente haga lo que sabe hacer -diseñar y construir- y libéralos de tantos papeleos y reglas como sea posible.

Toda crítica necesita proponer alternativas, así que esta es mi receta para evitar la trampa litúrgica y promover una mejora contínua real:

• Sé consciente, cuestiona la necesidad del proceso: una buena manera de probar qué tan valiosa es una ceremonia o práctica para un equipo, especialmente si empieza a oler a liturgia, es hacerla voluntaria. Si tiene valor para los miembros del equipo perpetuarán la práctica y su utilidad estará fuera de cuestión. Si abandonan la práctica, significa que ha llegado el momento de buscar alternativas. Esto es auto-organización.
• Sé flexible y prueba cosas nuevas, en su plenitud: algunas prácticas ágiles necesitan tiempo y entrenamiento para que funcionen de verdad. Al principio es difícil y la gente se resiste al cambio. Como equipo, sed disciplinados cuando decidáis probar una práctica, adoptarla en su integridad, con compresión absoluta por un periodo de tiempo. Si resulta efectiva, podéis decidir incorporarla permanente en vuestro proceso.
• Comprueba la moral del equipo a menudo: mediante retrospectivas, conversaciones cara a cara, encuestas anónimas o cualquier otro medio. Pregunta a la gente lo que necesita para trabajar bien. Averigua sus aspiraciones y expectativas y emprende acciones para aumentar la motivación.
• Encuentra el equilibrio: cuando la motivación falla, la disciplina y las buenas prácticas prevalecen. Pero no podemos apoyarnos únicamente en la disciplina para lograr el éxito ya que la disciplina tiene un precio que pagamos en términos de moral del equipo. La motivación tiene el mismo efecto que la disciplina sin pagar ese precio.

Una última cita del maestro para cerrar este post:

Adapta lo que es útil, deshazte de lo que es inservible, y añade lo que es genuinamente tuyo

- Bruce Lee