No todos los equipos Scrum son ágiles: Falso Agile
Fake Agile: ¿Son ágiles todos los equipos Scrum?
No, desgraciadamente no todos los equipos Scrum son realmente ágiles.
Me explico: Un equipo Scrum se define por trabajar según el marco Scrum: Así que tiene sprints, ciertos roles y rituales. Y puesto que el propósito del marco Scrum es ayudar a los equipos a trabajar de forma ágil, Scrum debería hacer automáticamente ágiles a todos los equipos, ¿no?
Desafortunadamente, en la práctica, las organizaciones siguen introduciendo Scrum una y otra vez y, como resultado, los equipos son todo menos ágiles. A menudo se habla entonces de “Zombie Scrum”.
¿Qué es “Fake Agile”?
“Fake Agile” se refiere a los equipos que trabajan oficialmente con marcos y métodos ágiles, pero sin tener ciclos de aprendizaje reales con los clientes. Fake Agile significa, por lo tanto, que o bien a) no se entregan incrementos iterativos a los clientes o bien b) la retroalimentación directa del cliente sobre el incremento no se utiliza para la priorización a corto plazo.
¿Cuáles son las causas del Falso Agile?
Hay muchas razones para el “Fake Agile”. En mi experiencia, las causas más comunes del Fake Agile en la práctica son las siguientes:
Falso Agile Causa #1: No hay comentarios de los clientes
Si un equipo ágil no recibe información directa de los usuarios, no puede trabajar de forma ágil. En la práctica, las peticiones de los clientes suelen ser formuladas por la dirección y transmitidas a los equipos a través de los propietarios de los productos – Los verdaderos bucles de retroalimentación con los clientes se desvanecen o ni siquiera existen.
Un equipo ágil necesita el contacto directo con el cliente.
Falso Agile Porque #2: Centrarse en la velocidad y los puntos de historia
¿Necesitamos decir mucho más sobre los puntos de historia en 2025? Creo que todos hemos tenido suficiente experiencia de hasta qué punto centrarse en la velocidad y los puntos de historia obstaculiza el beneficio para el cliente.
Un ejemplo: ¿Qué ocurre si una función está formalmente lista tras la primera iteración, pero aún no consigue el beneficio para el cliente? Si el beneficio para el cliente es importante para nosotros, trabajaremos en él hasta que se consiga realmente. Al final, puede que tardemos 3 iteraciones, pero al menos el cliente ya está contento.
Pero espera, ahora mi jefe viene de repente a la vuelta de la esquina y se queja de que mi equipo realizó menos puntos de historia en el último sprint. Así que habría sido mejor para mi velocidad si simplemente hubiéramos dejado la función no valiosa y hubiéramos trabajado directamente en la siguiente función para poder crear más puntos de historia.
Qué tontería, ¿verdad? Si repetimos este proceso durante unos meses más, tendremos un producto con un montón de funciones que generan muy pocos beneficios para el cliente.
Por eso no es de extrañar que tanto los clientes como los equipos de desarrollo se sientan insatisfechos y se marchen.
En términos más generales, se trata de una ley ahora bien conocida: Ley de Goodhardt
“When a measure becomes a target, it ceases to be a good measure.”
Falso Agile Causa #3: La dictadura del dogma
A los ingenieros les encanta que haya reglas fijas para todo. Eso hace que los procesos sean planificables.
Entonces, ¿qué tal si también fijamos completamente nuestras formas de trabajar con reglas? ¿No sería genial? No, no lo sería.
Sólo con Scrum y sus muchas reglas y directrices, el trabajo ágil ya se siente como trabajar de acuerdo con directrices rígidas para muchos equipos. No debería ser así. Así que no lo empeores añadiendo más normas y directrices al trabajo ágil.
En los mejores equipos ágiles que conozco, el trabajo se siente humano, vivo, espontáneo y colaborativo. Y hay que reconocer que en la mayoría de los equipos ágiles no es así.
Los equipos de Agile deben tener al menos la libertad suficiente para poder colaborar de forma flexible con los clientes. Si las normas y los procesos lo impiden, habrá que revisarlos.
En este post, ya he escrito específicamente sobre los pasos necesarios para proteger a los equipos Scrum de Zombie Scrum: Arreglar Zombie Scrum
El falso Agile es real: ¿cómo protegerse?
Nada le protege totalmente de la falsa agilidad. Pero hay algo que puede protegerle lo mejor posible: Un proceso eficaz centrado en la mejora continua.
Por supuesto, esto empieza con unas buenas retrospectivas en las que los miembros del equipo puedan compartir abiertamente sus puntos de vista y deducir y aplicar eficazmente medidas de mejora.
Mientras este proceso funcione, no se perderá el potencial de agilidad real de su equipo.
Si quieres llevar tus retrospectivas ágiles al siguiente nivel, te recomiendo –naturalmente – Echometer, nuestra herramienta para retrospectivas. Puedes probarla gratis aquí: Prueba Echometer
