Cuando el framework se convierte en el jefe

¿Cuál es la diferencia entre una calabaza y un zapallo?

Puede sonar a pregunta muy sencilla, pero para quienes vivimos en el extremo sur del continente, conocer ciertas costumbres norteamericanas de primera mano, y no solo por la tele o por internet, es bastante difícil. No hablo de nosotros, claro, nosotros sí sabemos: hemos viajado harto. Pero para algunos familiares de tendencias más extremas es difícil no ingresar en esa interrogante sin terminar citando algún libro sagrado, con la interpretación humana de ciertas deidades. Y es fácil caer en eso.

Es imposible saberlo todo, y como no queremos quedar como personas que no piensan y que le preguntan todo a la IA ante la menor duda, a veces la única opción que queda es confiar en los más sabios, en nuestros ancestros, en los que venían antes.

Así nacen las frases que cierran conversaciones:

• «Así está escrito en la Constitución».
• «Todo tiempo pasado fue mejor».
• «Esto ya estaba predestinado a ocurrir».
• Y la peor de todas, al menos en nuestro rubro: «Porque Scrum lo dice».

Una frase curiosa, porque técnicamente Scrum no dice nada. Es un marco de trabajo, y su guía, de unas pocas páginas, no suele actuar como un jefe con opiniones sobre cómo mandar un correo o cómo diferenciar hortalizas. Y sin embargo, en muchas organizaciones funciona como un superior invisible: nadie lo ha visto, nadie lo cuestiona y todos le temen un poquito.

Hoy hablamos de lo que pasa cuando un marco de trabajo deja de ser una herramienta y se convierte en el último argumento de una discusión. Sin culpables, porque le pasa a cualquier equipo, incluido el nuestro.

Un ritual no es lo mismo que una práctica

La diferencia es sencilla. Una práctica existe porque sirve para algo. Un ritual existe porque existe. La Daily de las 9:15 puede ser cualquiera de las dos, y desde afuera se ven idénticas: las mismas caras, el mismo tablero, el mismo cronómetro. Lo único que las separa es si alguien puede explicar qué decisión se toma ahí que no se tomaría de otra manera.

Y ojo, que seguir el manual tiene su lógica. Nadie te despide por hacer exactamente lo que dice el marco. Si el proyecto sale mal, la culpa es del contexto, de los stakeholders o de la famosa «falta de madurez ágil». Si sale mal después de que te desviaste, la culpa es tuya. El marco se vuelve un seguro, no de calidad sino de responsabilidad. Cambiamos criterio propio por tranquilidad, y a veces ese trato es razonable. El problema aparece cuando ni siquiera notamos que lo firmamos.

Hay un dato que suele sorprender: la Guía de Scrum describe el marco como deliberadamente incompleto. Define las piezas mínimas y deja el resto en manos de quien lo usa. O sea, la guía te está pidiendo que pienses. Seguirla al pie de la letra sin pensar es como seguir una receta que dice «sazone a gusto» y poner cero gramos de sal, por si acaso.

A todo esto se suma un efecto de grupo. Si en el equipo nadie pregunta por qué existe una reunión, cada persona supone que los demás sí lo saben. Todos creen que alguien entiende el propósito, y ese alguien no existe. Es como un ascensor lleno de gente donde todos miran hacia arriba porque los demás miran hacia arriba.

Dos veteranos que ya lo vieron

En enero de 2009, Martin Fowler describió en su blog lo que llamó «Flaccid Scrum» (Scrum flácido): equipos que adoptaban las prácticas de gestión de Scrum, con sus reuniones, sus tableros y sus sprints, pero descuidaban las prácticas técnicas. El resultado, según Fowler, eran sistemas cada vez más difíciles de cambiar y un ritmo de entrega que se iba frenando. Su diagnóstico es interesante porque no culpa al marco: recuerda que Scrum deja fuera, a propósito, las prácticas técnicas, y que cada equipo tiene que ponerlas de su parte. Traducido: las ceremonias se pueden cumplir a la perfección mientras el producto se deteriora. Y nadie en la sala tiene por qué notarlo, porque la Daily salió impecable.

Otro veterano, Ron Jeffries, uno de los firmantes del Manifiesto Ágil, habla de «Dark Scrum» para referirse a Scrum practicado de manera opresiva. Para él, si no hay alegría en el trabajo, algo se está haciendo mal. No es una crítica a la idea original, es un aviso: cuando un marco se aplica como obediencia, puede terminar sirviendo justo a lo contrario de lo que prometía.

La prueba de las dos semanas

No hace falta demoler nada. Elige una ceremonia y conviértela en hipótesis: «Creemos que la Daily nos sirve para detectar bloqueos antes de que cuesten un día entero». Una hipótesis se puede comprobar. Durante dos sprints, anota cuántos bloqueos reales se detectaron ahí y cuántos habrían aparecido igual por el chat o en el pasillo.

Si la cuenta sale buena, ahora tienes un dato para defenderla. Si sale pobre, tienes un dato para cambiarla: acortarla, hacerla dos veces por semana, moverla de horario o dejarla como está sabiendo por qué. Y existe una tercera posibilidad, la más divertida: que al probar descubras que la costumbre sí aportaba algo. Hay ceremonias que parecen costumbre y resultan ser el pegamento del equipo. Perfecto, ahora lo sabes.

Solo un cuidado: no pases del reflejo de obedecer todo al reflejo de cortar todo. Quien rechaza el marco por sistema es tan predecible como quien lo acepta por sistema.

Así que ya sabes, la próxima vez que alguien diga «porque Scrum lo dice», responde con curiosidad: «¿y qué problema nos ayuda a resolver?». Si hay respuesta, estupendo. Si no, ya tienes tema para la retro.

Nos vemos en el próximo Sprint 🚀