En toda transición a equipos y metodologías ágiles, existe un riesgo de mantener hábitos y prácticas antiguos que sobreviven disfrazados de “adaptaciones de agile” pero que a medio plazo van a constituirse en bloqueos estructurales, en antipatrones agile que poco a poco refuerzan la involución o algo peor, un pastiche de lo antiguo y lo nuevo. En este artículo os desvelo cuatro de estos antipatrones identificados gracias a la involuntaria ayuda de los usuarios de Taiga, una plataforma de gestión de proyectos.
Taiga, detectora de síntomas
Se cumplen 5 años de la salida al mercado de Taiga, la plataforma de gestión de proyectos ágiles elegante, open source y pensada para equipos multidisciplinares, que ha conquistado a miles de equipos y organizaciones en todo el mundo (no en vano Taiga está traducida a más de 20 idiomas). Surgió de una de las primeras “semanas de innovacion personal“ (PiWeeks) de Kaleidos y ya está fuera de control.
El caso es que desde este observatorio privilegiado que es Taiga, para muchos equipos LA HERRAMIENTA de apoyo a las metodologías ágiles, tenemos acceso a una información de altísima calidad para detectar los síntomas que conducen a los antipatrones agile. ¿Pensáis que quizá me refiero a estudios estadísticos de nuestra base de cientos de miles de usuarios en todo el mundo? ¿a pormenorizadas encuestas anuales? En absoluto, solamente tenemos que escuchar las peticiones de nuevas funcionalidades que nos piden los usuarios, esa “única funcionalidad faltante” que hará de Taiga “la plataforma perfecta”. La gran mayoría de estas peticiones son la punta del iceberg de un antipatrón, vamos con una selección de cuatro.
Captura de pantalla de Taiga en farsi, uno de los 20 idiomas a los que está traducido, y con soporte RTL
Antipatron agile I: workflows y permisos para cumplir con ISO
Se suele expresar tal que así “En esta organización es importante seguir un proceso concreto de aprobaciones y revisiones para mantener unas normas ISO y eso implica workflows con permisos muy específicos de forma que nadie pueda cometer errores“.
Aquí encontramos una falacia y un problema. La falacia es que precisamente las normas ISO sobreviven tan bien durante años porque se aseguran de no mezclar procesos con implementaciones concretas, no es cierto que ISO obligue a una hiperfiscalización de ciertos flujos de trabajo. Y el problema en relación a Agile es que este enfoque prima una mínima delegación en lugar de máxima delegación en base a los principios lean. En Agile se trata de poder dar en cada estamento de una organización la máxima responsabilidad que puede asumirse favoreciendo la autonomía y el compromiso entre los equipos. ISO no tiene nada que decir a este respecto, por mucho que se empeñen los consultores.
Cuando se busca crear un marco en donde hay que pedir permiso para nunca tener que pedir perdón, el principio del manifiesto ágil que dice “Individuos e interacciones sobre procesos y herramientas“ se arrincona completamente y muy rápidamente las personas pasan a ser sujetos pasivos de un modelo que en realidad (re)quiere que sean protagonistas, que puedan asumir riesgos y que puedan evolucionar; es imposible que se den las condiciones para que las promesas de Agile se hagan realidad algún día con este sustrato.
Antipatrón agile II: No se respeta el compromiso de equipo
Se suele expresar así “En esta organización queremos poder intervenir a medio camino del sprint si nos damos cuenta de que el equipo avanza más rápidamente de lo esperado (añadimos más tarea) o han surgido nuevas prioridades en el backlog (interrupción urgente)“.
En realidad, he mentido, así no nos llega la petición, sino en su reverso “Estamos hartos de que nos cuelen cosas a mitad de sprint. Necesitamos que Taiga impida a ciertos usuarios hacernos ese atropello“. Taiga ya lo permite pero aquí la clave es entender que en particular Scrum como metodología ágil necesita, casi exige, que los equipos puedan asumir ciertos compromisos con una entrega al final del sprint. En virtud de ello, seleccionan un conjunto de historias de usuario prioritarias que puedan acometer. Ese compromiso de equipo clave queda dinamitado en el momento en el que algún stakeholder se arroga el derecho a modificar un sprint en curso, invalidando el compromiso de equipo y generando mucha frustración. Permite al equipo redefinir su propio compromiso si eso tiene sentido a mitad de sprint.
Este antipatrón suele acompañarse con una huida hacia adelante muy habitual; pasar de Scrum a Kanban, ya que este último es un modelo más orgánico en donde no existen los sprints. Desafortunadamente, entonces el tablero Kanban reflejará en forma de atascos en una o más columnas el mismo problema subyacente, la interrupción y cambios de prioridad constantes.
Un kanban con el nivel de zoom al mínimo sirve para detectar cuellos de botella
Antipatrón agile III: Todo por la velocidad del sprint
Éste nos llega así expresado “En Scrum, solo las historias de usuario completadas en un sprint pueden sumar sus puntos de historia pero eso nos provoca que trabajos parciales no cuenten para la velocidad del sprint y den una mala imagen“. Es uno de mis favoritos y uno de los más polémicos con hilos de discusión eternos.
Un buen gráfico de burndown chart es casi el santo grial de Scrum. Representa un avance a buen ritmo en el cierre de historias de usuario. El problema surge cuando no conseguimos cerrar historias de usuario y aún así pretendemos contabilizar un porcentaje significativo de los puntos asociados a estas historias de usuario. Y ello a pesar de que el Product Owner y otros stakeholders no pueden validar la historia de usuario con la consecuencia de que el valor en ese sprint para ella debería ser cero. El origen de estos sprints desastrosos en donde de 50 puntos llegan cerrados apenas 5 es múltiple. Puede ser por una mala estimación (fácil de justificar al comienzo pero más difícil tras meses de proyecto), una tendencia a comenzar todas las historias de usuario el primer día de sprint y pretender cerrarlas todas a la vez la víspera de la demo o el mismísimo antipatrón anterior, entre otras causas.
Para Taiga sería muy fácil otorgar un valor porcentual a la historia de usuario en virtud de las subtareas cerradas y así maquillaríamos el valor numérico de puntos cerrados en ese sprint, pero entonces estamos facilitando burndown charts preciosos que no muestran valor entregado, tan solo esfuerzo invertido.
Una gráfica de burndown maravillosa, “quemando” funcionalidad a buen ritmo ¿pero es realmente así?
Antipatrón agile IV: Planificación anticipada
Que suele venirnos así “En esta organización hemos implantado Agile con Scrum, creamos un backlog, priorizamos, estimamos y luego creamos todos los sprints rellenos para saber cuándo tendremos terminadas todas las funcionalidades“.
Scrum, Kanban y modelos Lean gestionan muy mal la planificación anticipada cuando la calidad de la información es baja, que es lo más habitual. En su lugar, se han especializado en aguardar hasta el momento óptimo para estimar, evaluar, priorizar y desarrollar con la intención de reducir desperdicio. Hay personas que no pueden conciliar esta visión y utilizan el vocabulario agile pero los modos waterfall creando n sprints con las historias de usuario ya programadas en cada ciclo.
Esto no es solo un sinsentido sino que va a dar como resultado un caos en cada pequeña replanificación. Si quieres garantizar un resultado concreto de un proyecto para una fecha, entonces invierte mucho tiempo en diseñar lo que quieres y luego evita cambiar el plan a toda costa. Agile, por contrario, nos dice “Respuesta ante el cambio sobre seguir un plan“. La promesa de Agile es que para cualquier fecha futura dada, se tendrá el producto de mayor valor y menor desperdicio pero no dice nada de qué en concreto compondrá ese producto. Waterfall a cambio sigue el camino inverso, garantiza qué contendrá un producto para una fecha determinada pero no se preocupa del valor entregado ni de cuánto desperdicio generó por el camino.
Un ejemplo de proyecto pequeño de Taiga usando Scrum, son más habituales los de más de 10 sprints y ahí es donde puede aparecer este antipatrón
… y una mentira bien gorda “En Agile está prohibido estimar el esfuerzo de una tarea”
Nos reservamos para el final un asunto muy polémico en los círculos agilistas en parte promovido por los intereses creados por una venta rápida de agile en determinados contextos. En Agile es valiosísimo estimar independientemente de que no podamos predecir, como decíamos en el cuarto antipatrón, qué expresión concreta tendrá un producto en una fecha futura. Para empezar, estimar sirve para dotar de calidad a una historia de usuario y manejar su prioridad con conocimiento de causa. No son cuestiones contradictorias aunque a menudo se emplea una en un ejercicio falaz de sine qua non.
Lo que es cierto es que estimar es un proceso muchas veces laborioso para el que no se reserva tiempo de calidad y con altísimo riesgo de desperdicio. Eso sí, hay que saber “cuántas capas de pintura” de estimación dar a cada historia de usuario en cada momento.
Por cierto, conscientes de este enorme reto en los equipos, Taiga 5 viene con Taiga Seedtime, una pequeña herramienta adicional para facilitar las estimaciones que confiamos que permita a los equipos realizar esta labor tan interesante con mucha mayor frecuencia.
Taiga Seedtime con un filtro antispoiler
Conclusión
Construir un producto como Taiga, con una base de usuarios tan grande y multinacional, empleado en pequeñas startups y grandes multinacionales, nos ha permitido descubrir hábitos y comportamientos que desean sobrevivir a toda costa. Parecen relativamente universales y más intensos durante las transiciones a agile pero nadie se encuentra a salvo de querer pedirle a la herramienta que le resuelva una carencia en su flujo de trabajo. Nos hemos resistido con Taiga a ceder a estas presiones y, en su lugar, hemos ido incorporando otras funcionalidades que atacan los antipatrones, no los síntomas que nos relatan los usuarios.
Tras casi dos décadas del manifiesto ágil y varias más desde el modelo Lean, no ha surgido ningún marco de trabajo multipropósito que resuelva mejor que agile el escenario de incertidumbre y velocidad de vértigo de la era de Internet. No es la panacea y muchos expertos agilistas se refugian en la culpabilización de una mala praxis ante el fracaso del modelo en según qué casos, cuando quizá hay que plantearse si agile era el camino correcto. Lo que sí es cierto es que hay una gran probabilidad de fracasar con un agile disfuncional, un agile que persigue las promesas del nuevo modelo pero que arrastra formas y métodos antiguos con excusas y miedos venidos del pasado. Una fórmula para el desastre garantizado.
Si quieres leer más, escribí este post sobre cómo implementar metodologias agile en una startup tecnológica.
Para acabar incluyo un video preparado por Grupo Digital con motivo del evento “Más allá del Ágile” en el que participé hablando precisamente de antipatrones ágiles.