He perdido la cuenta de la cantidad de empresas que he visitado las cuales, pretendiendo hacer Agile a ultranza, se enfrentan a serios problemas de retrasos en los plazos y falta de calidad en los entregables. La justificación siempre es la misma: que el problema no es Agile sino que no están haciendo Agile bien. Que el problema es que no cierran una release verdaderamente estable en cada sprint o que la descripción de cada tarea en JIRA cabría perfectamente en un tweet, o que los tests son insuficientes, o cualquier otra excusa justificando la disfuncionalidad en base a una falta de ortodoxia. Pero es falsa la creencia extendida de que más Agile arreglará los problemas de una empresa con dificultades para producir versiones estables dentro de los plazos estipulados. A renglón seguido contaré la historia que nos ha traído a la situación actual. Me ha quedado un post algo largo, pero prometo al lector paciente que es todo “lean”, sin circunloquios ni banalidades.
Agile nace gestado por la Primera Burbuja Punto.com
Agile nació poco después de que creciese la Primera Burbuja Punto.com. Agile apareció como una metodología para que las consultoras pudiesen gestionar de alguna forma su relación con clientes que no sabían exactamente lo que querían. Agile no se inventó durante la década de los sesenta para el Programa Apolo porque la misión era poner a un hombre en la Luna antes del 1 de enero de 1970. No necesitaban una sucesión de lanzamientos con mejora contínua de los resultados. Sí necesitaban, en cambio, nuevas herramientas como IBM IMS para gestionar el inventario del Saturno V o las metodologías estilo Waterfall de los 70 que siguieron vigentes durante muchos años tras su invención. Pero en el año 2000, con clientes que no sabían ni a qué planeta querían llegar o, peor aún, cambiaban el planeta de destino según avanzaba el proyecto, era muy difícil hacer un inventario de necesidades y presupuestarlas. Entonces se inventó algo para facturar al cliente no una cantidad fija por proyecto cerrado sino por “time & materials” (horas/hombre y cualquier otro coste imputable) sin límite presupuestario. Obviamente, si el cliente pagaba por horas en lugar de por resultados era necesario demostrarle que los programadores estaban trabajando de la forma más eficiente posible. Y de ahí surgieron todas las prácticas ágiles para optimizar la productividad de los programadores exprimiéndoles como cítricos.
Agile emigra a las grandes corporaciones
Aproximadamente un lustro después de que las consultoras introdujesen Agile, los gestores de proyectos de los clientes empezaron a pensar que si la metodología funcionaba tan estupendamente para las consultoras entonces funcionaria igualmente bien para los proyectos internos de la compañía. Como las grandes empresas cambian despacio, les llevó aproximadamente otros cinco años, hasta 2010, entrar de lleno en la cruzada por el agilismo.
Fué en este momento cuando se empezó a complicar la cosa. No es lo mismo hacer un proyecto táctico para un departamento de una gran corporación que un megaproyecto de transformación empresarial de gran calado. Las consultoras web muy a menudo trabajaban para directores de desarrollo de negocio que estaban frustrados con la lentitud de su servicio de informática interno respecto de la velocidad que había tomado el mercado. Querían soluciones rápidas de negocio, y no les importaba si estaban bien o mal integradas con el resto de los sistemas de la casa. Sólo buscaban correr para no perder el tren de Internet. Agile primaba la entrega sobre la calidad, porque la consultora tenía un tiempo de vida limitado para conseguir algún éxito rápido antes de que les cancelasen el proyecto o fuese absorbido por el departamento de informática del cliente. Pero a un mando intermedio de una gran empresa casi nunca le conviene priorizar la entrega sobre la calidad por dos motivos: a) vive permamentemente en competencia por el ascenso con otros mandos quienes están siempre pendientes para descubrir dónde se ha equivocado; y b) a las empresas les cuesta tanto cambiar organizativamente que la velocidad de desarrollo no es casi nunca un cuello de botella. Es más, el tiempo de codificación sólo supone, como mucho, el 30% o el 40% del tiempo de trabajo de un programador. Al obcecarse con reducir el tiempo de programación se optimiza sólo el 30% del tiempo y no se hace nada respecto del otro 70%. Entonces, el cliente puede acabar pagando “time & materials” de programadores quienes, siendo muy eficientes en su labor, pasan no obstante una fracción significativa de su tiempo esperando.
Se eliminan los gestores de cuenta
Los vendedores y gestores de cuenta en las consultoras provocaban con frecuencia el siguiente problema serio: en un caza de combate el piloto puede normalmente hacer sólo tres o cuatro maniobras de alta velocidad antes de agotar su reserva de combustible y tener que volver a la base. Análogamente, los gestores de cuenta tenían tendencia a pulsar el botón que activaba la postcombustión cada vez que se veían al borde de ganar o perder una cuenta porque les faltaba esta o aquella funcionalidad en el producto. Esto dejaba a los programadores quemados y agotados y encima con frecuencia no servía para lograr los objetivos comerciales deseados. Tras una serie de motines de los programadores, la solución fue quitar el poder a los gestores de cuenta para dárselo a los programadores.
Se decidió que los programadores debían hablar directamente con los clientes, ya que los gestores de cuenta entendían y trasladaban mal los requisitos. Y que los programadores debían auto-organizarse fijando sus propios objetivos y estimaciones. ¡Bien! ¡Poder para el pueblo!
Se decidió también que los programadores podían programar y reunirse con los clientes al mismo tiempo. De todas formas si no se reunían con el cliente se tenían que reunir con el gestor de cuenta lo cual es casi lo mismo ¿no?
De nuevo, esto funcionó bien para las consultoras. Más horas hablando con el cliente estrechaban el vínculo emocional con él y proporcionaban más información a la consultora para hacer venta cruzada.
Pero ¿qué pasó en los grupos de trabajo de los clientes? Bien. Lo que sucedió fué básicamente que Agile tomó el control estratégico de la empresa. En lugar de un equipo directivo fijando la visión y misión y un equipo operativo tratando de ponerla en práctica, la empresa pasó a estar gobernada por un grupo de ejecutivos desvalidos que mendigaban al cognitariado agilista si era posible hacer esto o aquello. Cualquier intento de dirigir la empresa fuera de los límites de Agile era vaticinado como una hecatombe segura por el Oráculo Agile. Y así Agile pasó a convertirse en una cuestión de fé.
Respecto de la comunicación, si las empresas ya estaban saturadas de reuniones, Agile potenció todavía más reuniones. Y además introdujo la idea de que los usuarios pueden (y deben) crear las historias «de usuario». El problema es que los usuarios carecen normalmente de formación en diseño estructurado de sistemas y, por consiguiente, no pueden crear una especificación de calidad porque nadie les ha enseñado cómo hacerlo. Tienen un conocimiento experto de su negocio, pero necesitan coaching de un analista-programador para plasmar dicho conocimiento en un papel.
Se veta a los senior
Una consultora obtiene beneficios de la diferencia entre lo que le cobra al cliente y lo que le paga a sus empleados. Por consiguiente, una consultora rentable es, por definición, una horda de juniors. No todas las consultoras son así, por supuesto, algunas son boutiques de un puñado de verdaderos expertos, pero si la consultora tiene más de 10 empleados entonces el 80% de ellos son junior porque las consultoras existen tanto para hacer lo que el cliente no sabe hacer como para que éste les lance toda la basura que no quiere procesar.
Los senior tienen mala cabida en una metodología Agile. No da tiempo en un único sprint de producir un buen análisis o una arquitectura de software para un proyecto complejo. Además, la presión constante por alcanzar el sprint abona el terreno a peligrosísimos errores de diseño. Agile microgestiona a los senior obligándoles a acudir a reuniones diarias de control. Y es fácil eliminar miembros de alto potencial identificándoles falsamente como de bajo rendimiento simplemente porque no siguen a pies juntillas los sprints por absurdos que estos sean.
Un cliente con sistemas de información complejos quiere personal senior entre sus empleados. Quiere arquitectos capaces de aprehender todas las interacciones sutiles entre una miriada de sistemas de información y de adquirir una visión holística desde el alto nivel de las necesidades de negocio hasta los detalles de la electrónica de red. Esto simplemente no casa con Agile.
Se introducen métricas envenenadas
Junto con Agile, se introdujeron ciertas “prácticas Agile”. Algunas ya existían previamente con otro nombre, estilo las retrospectivas antaño conocidas como post-mortems, excepto que el nombre era muy tétrico y por eso se cambió y se le añadieron al método algunas viñetas graciosamente elocuentes.
Algunas prácticas fueron definitivamente un avance: Domain Driven Design, Integración Contínua, Refactorización, etc. Otras introdujeron caballos de Troya.
El primer troyano fueron las Historias de Usuario. En la época del diseño estructurado se abogaba por estimar el esfuerzo requerido usando métricas como los Puntos Función o la Complejidad Ciclométrica. Los puntos función, básicamente, consistían en medir la complejidad de los datos de entrada y los datos de salida y estimar que el esfuerzo requerido para desarrollar un programa sería proporcional a la complejidad requerida para manipular los datos. Algunas empresas como IBM llegaron a poder producir estimaciones muy fiables para determinado tipo de proyectos con estas métricas. Pero en las Historias de Usuario no se trataba tanto de estimar el esfuerzo requerido como el valor que aportaría al cliente la funcionalidad. Esto era debido a que la consultora estaba interesada en cobrarle al cliente no por su coste de producción más un márgen sino por el valor añadido. Hablando de valor y no de coste se evitaba que el cliente dejase a la consultora cobrando “time & materials” más un 15%. Pero en los proyectos internos en grandes empresas el valor que añade cada funcionalidad es mucho menos relevante puesto que las grandes empresas casi siempre operan en oligopolios que pueden repercutir sus sobrecostes a los clientes. Lo que sí es crucial es saber cuándo estará terminado y qué hará, debido a que puede que se avecine una campaña de Navidad o una salida a bolsa. Pero ese ¿cuándo? y ¿qué? es justamente lo que NO garantiza Agile. En cambio, la sucesión interminable de releases incompletas lo que acaba generando es una profunda desazón en los usuarios y patrocinadores quienes empiezan a tener la sensación de que el proyecto no estará terminado nunca.
El segundo troyano fue Test Driven Design (TDD). No es que TDD sea para nada malo en sí mismo. De hecho, ningún programador profesional hoy en día escribe código sin un juego de tests que lo acompañe y eso es por muy buenos motivos demasiado largos y técnicos para enumerarlos aquí. El problema de TDD fué que generó la idea de que el código estaba «listo» cuando estaba «listo para lanzárselo a control de calidad» como quien pasa una patata caliente. Si pasaba los tests entonces el código funcionaba, fin de la historia. La mil veces repetida excusa de los programadores «en mi PC funciona» pasó a ser «pasa los tests». Gracias a la integración continua, todas las máquinas virtuales podían tener fácilmente la misma configuración, luego ya no sucedía que funcionase en una si y en otra no, pero pasar los tests no implicaba que el programa hiciese en absoluto lo que el cliente esperaba que hiciese, pues, cómo ya hemos explicado anteriormente, quién había redactado la historia de usuario no sabía explicar exactamente lo que necesitaba. De postre, los tests escritos por el programador nunca incluyen pruebas de carga, puesto que son muy tediosas de escribir y además bloquearían el sistema de integración continua. De modo que incluso si el software funciona en producción lo hace a la velocidad de un trasatlántico a pedales.
El tercer troyano fueron los Product Backlogs. Estos priorizaban la aceptación de cambios y el desarrollo sobre la planificación. La forma en la que un backlog fuera de control aniquila un proyecto la describí en otro post titulado lo que sucede cuando un software se convierte en un agujero negro, de modo que no voy a extenderme aquí sobre este punto.
Se arregla Agile con más Agile
Como corolario de todo lo anterior, la situación típica es una de las siguientes:
a) Si la empresa es pequeña, el CEO ha caído prisionero de los programadores. Cada vez que intenta pedir algo, los programadores le responden que debe conseguir más recursos, o más inversión ¡o traer menos clientes! porque no les da tiempo de atenderles.
b) Si la empresa es grande, hay una gran cantidad de proyectos bloqueados a la espera de que un tercero entregue algo. El proyecto avanza, pero lo hace a una velocidad exasperantemente lenta y no exenta de sobresaltos.
El diagnóstico siempre es invariablemente el mismo: no se está haciendo Agile correctamente. Pero ¿quién puede hacer Agile correctamente? y… ¿de qué manera? si ya se ha intentado todo y se han mantenido sempiternas reuniones.
Entonces ¿Cómo salvar el proyecto?
1. Se deja de esperar a que los usuarios produzcan ninguna especificación. En cambio, se asignan analistas para trabajar con ellos en la producción conjunta de especificaciones.
2. Cada sprint durará lo que tenga que durar. ¿Por qué dos o tres semanas? Tampoco seis meses, para evitar los sustos que daba Waterfall. Puede haber puntos de control intermedios, pero si se necesitan ocho semanas para producir algo estable, se necesitan ocho semanas, y no cuatro sprints de dos semanas.
3. Se resucitan los Gantt, si ¡horror! Se restituyen los análisis de caminos críticos que muestren quién está bloqueando a quien y dónde. Se instalan pantallas gigantes que muestren en tiempo real el grado de progreso del sprint, los retrasos acumulados, el estado de los tests de integración y la actividad de usuarios en producción.
4. Se para en seco la aceptación de nuevas funcionalidades hasta que se estabilicen por completo todas las que hay. Es decir, desde mañana y hasta nuevo aviso los cambios NO son bienvenidos en la planificación del proyecto.
5. La decisión sobre la fecha de release pasa al departamento de control de calidad. Será este, de común acuerdo con los usuarios, quien valide que el software producido cumple con los requisitos.
6. La misión de sprint es cumplir expectativas. Al cuerno con la verborrea sobre valor añadido al negocio o restricciones técnicas insalvables. No se acepta ninguna excusa técnica ni organizativa en el último minuto para justificar por qué el cliente no obtendrá lo que esperaba obtener.
7. Cada programador arregla los bugs que él mismo haya introducido. Además, no gozará de más tiempo sobre el que tuviera pre-asignado a sus tareas. El programador no sufrirá penalización salarial ni de carrera profesional por un bug, pero tendrá que arreglarlo haciendo horas extra no retribuidas.
8. Se diseñan informes que muestren claramente cuánto tiempo se está dedicando a : desarrollo, corrección de bugs, soporte a cliente y reuniones. En la contabilidad analítica se diferenciará claramente el coste de producción del coste de soporte.
9. Quedan abolidas las reuniones. En lugar de una metodología que fomente que la gente se reuna y hable con la mayor frecuencia posible, se intenta que los programadores tengan que ir al mínimo número de reuniones. Como máximo una por semana. No se puede ser creativo y explicar lo que se está haciendo al mismo tiempo. El daily se substituye por un chat online donde todos los programadores y gerentes puedan acceder de forma inmediata a cualquier otro miembro del equipo en caso de necesidad urgente.
10. Los programadores son obligados a documentar lo que están haciendo. Si bien no están obligados a estar cada dos por tres de pie en una sala, sí deben mantener actualizado un repositorio documental con el progreso y detalles de todo su trabajo ya que no existe tal cosa como el código autodocumentado. La herramienta puede ser JIRA, Redmine, un wiki o incluso un blog donde los programadores compartan sus progresos en lugar contarle a nadie lo que están haciendo o enviar un mail a una lista y crear un hilo interminable. Evitar las reuniones no implica desinformarse. El desafio es mantener a todo el mundo informado sin necesidad de mantenerlo permanentemente reunido.
11. Se añade una capa de metodología de optimización global sobre Agile.
12. Se decreta la Anarquía de los Programadores. Podrán reirse a carcajadas de una decisión. Podrán ser sorprendidos trabajando en cosas aparentemente no relacionadas en absoluto con el proyecto. Podrán soñar con dragones.
Posts relacionados:
Las zonas grises de Agile.
Cheat Sheet de marrones en un proyecto.
El oportunismo del agilismo (Luis Lobo).
