Me he preguntado por un largo tiempo si acaso la agilidad es más que mi trabajo, más que un cúmulo de ideas, principios, valores y herramientas que ayudan a aumentar números y estadísticas en una organización, o acaso es parte de ese pedernal que impulsa mi vida y me apasiona al saber que estoy generando lazos e impactando en personas, equipos, organizaciones y ellas a mí.
Cuando comencé con este blog tenía un norte claro, compartir conocimiento y experiencias. Pero poco a poco las ganas de escribir se fueron diezmando con el día a día que suele consumir a los soñadores. Ahora de a poco voy re descubriendo mi propia cruzada tomando este espacio como catarsis y haciendo retrospectiva cada tanto sobre la manera de renovar pasiones ante los muchos obstáculos que aparecen cada día al intentar transformar el mundo!!
Dejando un poco de lado la motivación que me trajo hasta aquí y claro hablando de esos obstáculos que me he encontrado en mi paso por distintos contextos que están adoptando la agilidad me he decidido a escribir sobre el ritmo sostenible en los equipos de trabajo colaborativo, que si bien muchas organizaciones parecen conscientes de su importancia, el status quo sigue siendo “trasnochar”, “el crunch”, “dar el 110%”, etc…y parece ser algo normal.
Las marchas de la muerte (metáfora que se refiere a una fecha inalcanzable con todo el equipo sufriendo) son un problema que aqueja a las industrias creativas desde tiempos inmemoriales.
Acercándome un poco más a una industria conocida para mí, los desarrolladores de videojuegos se enfrentan en su día a día a marchas de la muerte, que aumentan entre más avanzado esté el proyecto como una bola de nieve lo que lleva al agotamiento y al éxodo de la industria, justificado en gran medida con frases que seguramente suenen muy conocidas como:
“No estés en la industria del videojuego si no puedes amar las 80 horas de trabajo por semana, estás tomando el trabajo de alguien que realmente lo valoraría” y “Si no cumplimos el deadline nos cancelan el proyecto, ustedes verán”
Respecto al ritmo sostenible Rami Ismail resume que “Los equipos deben encontrar un ritmo sostenible que puedan trabajar a largo plazo. Esto significa trabajar cerca de 40 horas por semana la mayor parte del tiempo con períodos de crisis que no duren demasiado.”
Pero ¿cuánto puede durar ese periodo de “crisis” antes de convertirse en una marcha de la muerte que condena al fracaso el proyecto? Hay estudios que muestran la efectividad real de la crisis.
En medio de vagos recuerdos de un proyecto incendiado de esos que ni Uncle Bob puede apagar, buscando una estrategia que nos llevara a cumplir la fecha de entrega para el publisher “pedimos” al equipo que trabajará 6 días a la semana con una intensidad de 10 horas diarias, lo que nos llevó a un resultado similar a esto:
La primera semana fue una semana normal de ~40 horas. Las semanas 2 a 4 fueron las semanas de 60 horas (aumentando entre más cerca el deadline). Lo primero que notamos es que el tiempo extra en la semana 2 provocó que la velocidad aumentara de manera notable. ¡Más “cosas” se estaban haciendo! (¿Pero a qué costo?) Sin embargo, la velocidad disminuyó muy por debajo de la velocidad normal luego de eso, con tendencia a ser cada vez menos productivos.
¿Cómo es esto posible? Es sencillo, la gente se cansa, comete más errores y pierde el incentivo para crear valor. Como alguna vez charlamos con un viejo amigo:
“Un programador en un deadline a las dos de la mañana es como un borracho bailando, en ese momento cree estar en su estado de flow y ser el mejor bailarín, pero a la mañana siguiente cuando ve los videos lo mejor que puede hacer es borrarlos”, mejor conocido como el efecto código de borracho.
Ahora, claro que existe ese estado de “Flow”. Muchas veces vi equipos trabajando hasta la madrugada en un juego por el que se apasionaban mucho y llegaron a esa zona altamente productiva. Nunca duró más de un par de semanas y con un buen descanso luego de eso.
El error que los líderes suelen cometer es pensar que el efecto es también la causa. Pensar que obligar una persona a trabajar 80 horas a la semana los pondrá en estado de “Flow ”. Eso es como obligar a alguien a sonreír para que sea feliz. No funcionará.
Los límites del equipo necesitan ser entendidos. Una autopista llena al 100% de capacidad es un estacionamiento. Trabajar más horas para pretender ir más rápido es como intentar apagar un incendio con un vaso de agua (sin hablar de la deuda técnica que hará ir aún más lento en el futuro), consiguiendo que los proyectos se estanquen en esa marcha de la muerte interminable en la cual entre más horas trabajamos, más lento parecemos ir.
Y aquí es donde juega un papel importante el agente de cambio ágil, pues es necesario enfrentarse a los problemas con coraje… Si la marea sube, el barco también sube. Pues se necesita mucho coraje para comenzar un proyecto con ritmo sostenible y calidad técnica.
Existen maneras de evitar las marchas de la muerte y fomentar el ritmo sostenible, como limitar el wip o el slack time. Sin embargo algo de lo cual he obtenido mucho valor es sobre la creación de evidencia empírica sobre qué funciona y qué no.
Esta es la razón por la cual no hay una “regla” específica que defina cómo debe hacerse algo, “no hay un solo ritmo, sino varios y es bueno hacerse siempre la pregunta de cuál es el ritmo adecuado para cada cosa” Thomas Wallet.
Al final del día todo depende de las situaciones, interacciones y contextos que definen la realidad de cada equipo. La única manera de descubrir cuál es su propio ritmo sostenible es lanzándose al ruedo y averiguarlo!!
Pues ¿Qué más es la agilidad sino una expresión del método científico?
[1] “Scrum is a framework for developing and sustaining complex products.”
