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?
Por desgracia, en la práctica, las organizaciones siempre se las arreglan para introducir Scrum y hacer que sus equipos sean cualquier cosa menos ágiles. Esto se conoce a menudo como "Zombie Scrum".
¿Qué es un "falso Agile"?
El "falso Agile" se refiere a los equipos que trabajan oficialmente con marcos y métodos ágiles sin tener bucles de aprendizaje reales con los clientes. Por lo tanto, Agile falso significa que a) los incrementos no se entregan de forma iterativa a los clientes en primer lugar o b) la información directa de los clientes 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 que se produzca un "falso Agile". Según mi experiencia, las causas más comunes de "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
"Cuando una medida se convierte en un objetivo, deja de ser una buena medida".
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, ¿cómo sería si también pudiéramos definir completamente nuestros métodos de trabajo con las 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