El empirismo (y el pensamiento lean) como fundamento

Scrum se fundamenta en empirismo y pensamiento lean. Ken Schwaber y Jeff Sutherland lo dejaron claro en la Guía de Scrum 2020. El empirismo requiere tres pilares: transparencia, inspección y adaptación. Aquí está el quid de la cuestión: la adaptación no es opcional en scrum, es fundamental.

Pero ¿quién define qué es adaptación y que no? El problema surge cuando los equipos la usan como excusa para cambiar lo que resulta incómodo, sin preguntarse si esa incomodidad es precisamente lo que hace visible un problema más profundo. Scrum es mínimo y deliberadamente incompleto, pero sus elementos y reglas no son opcionales si afirmas que estás haciendo Scrum. Es flexible en las técnicas que empleas dentro del marco, no en los elementos fundamentales que lo constituyen.

Sin embargo, esta flexibilidad se convierte en una trampa cuando los equipos la utilizan como excusa. "Estamos siendo ágiles" se transforma en la justificación perfecta para eliminar prácticas incómodas sin entender por qué existen.

Shu Ha Ri: el mapa del aprendizaje que nos falta

El aprendizaje de cualquier habilidad tiene tres etapas:

Shu: se elige una técnica y, asumiendo que es correcta, se intenta imitar.

Ha: se coleccionan más técnicas.

Ri: se experimenta e inventan nuevas técnicas mezclando, combinando y modificando.

Las técnicas de etapa shu son aplicables en general. Las técnicas de etapa ri sólo funcionan en casos concretos, y requieren de conocimiento experto para saber cuándo y cómo aplicarlas.

Shu Ha Ri no es solo una teoría de aprendizaje elegante: es el mapa que nos ayuda a navegar esa línea entre adaptación y degeneración.

Shu Ha Ri es un concepto de aprendizaje usado en diversas disciplinas japonesas tradicionales, muy popularizado en artes marciales como el Aikido. El maestro Endō Seishirō Shihan lo explicaba así:

En Shu, repetimos las formas y nos disciplinamos para que nuestros cuerpos absorban las formas que crearon nuestros predecesores. Nos mantenemos fieles a estas formas sin desviación. En Ha, una vez que nos hemos disciplinado para adquirir las formas y movimientos, hacemos innovaciones. En este proceso, las formas pueden romperse y descartarse. Finalmente, en Ri, nos apartamos completamente de las formas, abrimos la puerta a la técnica creativa y llegamos a un lugar donde actuamos de acuerdo con lo que nuestro corazón y mente desean.

El Shu Ha Ri describe las etapas que atraviesa un scrum master desde la novicia que domina el proceso, pasando por la experimentadora que adapta las prácticas, hasta la maestra que trasciende el marco sin perder su esencia.

Pero aquí está el problema que reveló nuestro post de LinkedIn: muchos equipos quieren saltar directamente al Ri sin haber pasado por Shu y Ha. Quieren la libertad de la maestría sin el trabajo de entender primero por qué las prácticas existen.

¿Qué es exactamente "degeneración del marco"?

Antes de seguir, necesitamos una definición clara. Degeneración es cualquier cambio que reduce el empirismo (transparencia, inspección o adaptación) o que rompe un elemento de scrum para tapar problemas en lugar de hacerlos visibles.

La degeneración no es "romper las reglas". Es romper las reglas sin entender qué problema resolvían, sin medir el impacto del cambio, y generalmente porque queremos evitar la incomodidad que genera hacer visible lo que no funciona. También es degeneración sustituir una práctica por otra "más cómoda" sin demostrar que mantiene el mismo nivel de transparencia, inspección y adaptación.

Tres preguntas antes de adaptar cualquier práctica

Entonces, ¿cómo saber cuándo una adaptación es inteligente y cuándo es simplemente pereza disfrazada de agilidad?

1. ¿Entendemos el propósito original de esta práctica?

Tomemos el ejemplo que inició el debate: la daily scrum. La Guía de Scrum es prescriptiva en dos puntos: es un evento de 15 minutos y se realiza a la misma hora y lugar cada día laborable del sprint para reducir complejidad. Esto no es arbitrario. El timebox de 15 minutos fuerza la concisión pero permite que todos se sincronicen. La hora y lugar fijos eliminan la "fatiga de coordinación" de tener que acordar cuándo reunirse cada día.

Un matiz crítico: si tu equipo decide hacer "syncs" de 5 minutos, técnicamente ya no estás haciendo daily scrum como lo define la guía. Y aquí está la pregunta honesta que separa la adaptación de la degeneración: ¿entiendes por qué existen esos 15 minutos? ¿Tu sync de 5 minutos logra el mismo objetivo de coordinación diaria y detección temprana de impedimentos? ¿O es una señal de que nadie habla de impedimentos reales porque el equipo ha perdido la confianza para hacerlo?

Como señala Alistair Cockburn: "La velocidad del proyecto es la velocidad a la que las ideas se mueven entre mentes". Si tu práctica mantiene esa velocidad de movimiento de ideas, estás adaptando con criterio. Si la está reduciendo, estás degenerando sin darte cuenta.

2. ¿Tenemos evidencia de que la práctica actual no funciona?

No basta con que algo sea incómodo. El scrum efectivo a menudo es incómodo porque hace visibles los problemas que preferíamos ignorar. La evidencia no es "no nos gusta". La evidencia es "hemos observado durante X sprints que la retrospectiva no genera acciones concretas" o "el planning poker consume 3 horas y aún terminamos con estimaciones que fallan consistentemente".

3. ¿Cómo mediremos si la adaptación funciona mejor?

Este es el paso que la mayoría de los equipos olvida. Adaptan, pero no inspeccionan el resultado de la adaptación. Se eliminan las retrospectivas porque "no teníamos tiempo", pero nunca se pregunta: ¿mejoró algo al eliminarlas? ¿O simplemente dejamos de hacer visible que no estamos mejorando?

La inspección sin adaptación no es útil. Pero la adaptación sin inspección posterior es igualmente inútil. Es cambio sin aprendizaje.

Si vas a adaptar, mide algo antes y después:

• Porcentaje de días con impedimentos explicitados en la daily scrum.
• Número de acciones de retrospectiva completadas por sprint.
• Tasa de trabajo "casi Done" que vuelve atrás (indicador de calidad/DoD).
• Lead time o throughput (observa la tendencia, no el número aislado).
• Cumplimiento del sprint goal (sí/no + causas raíz cuando no se cumple).

No hace falta volverse académico: solo tener anclajes concretos que te permitan saber si el cambio mejoró, empeoró o no tuvo impacto. Porque lo contrario no es empirismo: es opinión no contrastada.

La paradoja de la maestría: los mejores equipos parecen no hacer scrum

David Johnson, en su reflexión sobre Scrum y Shu Ha Ri, plantea una observación provocadora: "Los equipos que están arrasando, entregando continuamente alto valor con alta calidad, pueden haber comenzado con scrum. Pero ahora probablemente verías pocos o ningún aspecto de scrum. El equipo ha evolucionado, el marco se ha disuelto. Lo reconoces cuando ves equipos así. Sientes su efectividad, los clientes están felices y el equipo está feliz".

Esto suena peligrosamente como lo que hemos estado criticando: equipos que han abandonado scrum. Pero hay una diferencia crucial. Estos equipos han alcanzado el nivel Ri no ignorando los principios de scrum, sino internalizándolos tan profundamente que ya no necesitan las formas externas para mantener el espíritu.

La diferencia es esta: un equipo en Ri puede explicarte exactamente qué problema resolvía cada práctica de scrum y cómo su enfoque actual lo resuelve mejor o de manera más adecuada a su contexto. Un equipo más inexperto en scrum simplemente te dirá "no necesitábamos eso" sin poder articular qué perdieron al eliminarlo o qué ganaron.

Antipatrones comunes

Basándonos en la literatura y en nuestra propia herramienta de antipatrones, estas son las señales más comunes de que un equipo ha cruzado la línea:

La retrospectiva que se cancela "porque no tenemos tiempo"

El Manifiesto Ágil no prescribe ceremonias concretas, pero sí prescribe el hábito en su principio 12: "A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia". Scrum convierte este principio en un evento explícito: la sprint retrospective.

Si la retrospectiva es lo primero que cancelas cuando hay presión, ¿en qué forma estás aplicando el empirismo?

Qué hacer mañana: haz una retrospectiva de 25 minutos, enfocada en identificar UNA acción concreta, con un responsable claro y una fecha de revisión. Si después de tres sprints no has implementado ninguna acción de las retrospectivas, el problema no es el tiempo que duran.

La daily que se convierte en reporte para el manager

La daily scrum es para el equipo, no para gestión. Si se ha convertido en un ritual de 45 minutos donde nadie escucha porque están preparando su siguiente reporte, has perdido completamente el propósito.

Qué hacer mañana: el equipo habla enfocado en el sprint goal y el plan para las próximas 24 horas. Si hay managers presentes, observan en silencio o, mejor aún, no asisten. La información de progreso se obtiene del sprint backlog visible, no de reportes orales. Si el manager insiste en asistir para "estar informado", el problema real es falta de transparencia en vuestros artefactos.

El sprint planning que solo mueve tickets

Si tu planning es básicamente "¿cuántos story points caben en este sprint?", sin discusión sobre el sprint goal, sin conversación sobre cómo abordar el trabajo complejo, has convertido scrum en un sistema de tickets glorificado.

Qué hacer mañana: haz obligatorio que cada sprint planning empiece definiendo un sprint goal antes de seleccionar trabajo. Discutid los riesgos principales y las dependencias antes de comprometeros. Si no podéis articular un sprint goal coherente que no sea "terminar estas historias", vuestro product backlog probablemente no está ordenado por valor sino por urgencia arbitraria.

La Definition of Done que nadie puede recitar

Si le preguntas a cualquier miembro del equipo "¿qué significa Done aquí?" y obtienes respuestas diferentes o vagas, no tienes transparencia. Y sin transparencia, los otros dos pilares del empirismo (inspección y adaptación) son imposibles.

Qué hacer mañana: cread una Definition of Done visible (en el tablero físico o digital), con ejemplos concretos de qué significa "Done" para vuestro contexto. Haced una auditoría ligera semanal: tomad un ítem terminado al azar y verificad si cumple realmente todos los criterios.

El contexto como variable decisiva

Aquí es donde la conversación se vuelve más matizada. Porque no todas las adaptaciones son iguales cuando consideramos el contexto.

Un equipo que trabaja en un dominio altamente regulado donde la mayoría del trabajo tiene espacios de solución bien conocidos no necesita el mismo nivel de empirismo que un equipo construyendo un producto innovador en un mercado volátil. Como Johnson señala: "En la industria bancaria altamente regulada, gran parte del trabajo tiene espacios de solución bien conocidos. Un ejemplo es incorporar gestión de identidad en los sistemas. Este es un espacio de problema y solución bien definido. No hay mucha incertidumbre, por lo que agregar la sobrecarga de un marco como Scrum, para reducir el riesgo en dominios altamente inciertos, no es necesario".

Pero reconocer esto requiere honestidad. ¿Realmente trabajas en un dominio predecible? ¿O estás usando "nuestro trabajo es especial" como excusa para evitar la disciplina del empirismo?

El marco como andamio, no como prisión

Hay una tensión fundamental en scrum que nunca desaparecerá: es suficientemente prescriptivo para ser útil, pero suficientemente minimalista para ser flexible. Como dijeron Sutherland y Schwaber en 2020: "El marco de scrum es intencionalmente incompleto. Se pueden emplear varios procesos, técnicas y métodos dentro del marco. Scrum envuelve prácticas existentes o las hace innecesarias".

La clave está en esa última frase: "envuelve prácticas existentes o las hace innecesarias". No dice "ignora prácticas que encuentres incómodas". Dice que si entiendes profundamente el propósito de una práctica de Scrum, podrías encontrar que ya lo estás logrando de otra manera, o que esa práctica específica no añade valor en tu contexto.

Pero esa evaluación requiere:

• Haber practicado la forma original lo suficiente para entenderla.
• Poder articular qué problema resolvía.
• Tener evidencia de que tu alternativa funciona mejor.
• Medir continuamente si tu adaptación sigue funcionando.

Sin estos cuatro elementos, no estás adaptando. Estás degenerando.

Tres equipos, tres respuestas diferentes a la misma pregunta

Para ilustrar la diferencia, consideremos tres equipos que enfrentan la misma pregunta: "¿Deberíamos acortar nuestra daily de 15 a 5 minutos?"

Equipo A (nivel Shu): "De momento no lo cambiamos: queremos practicar la forma estándar lo suficiente para entender qué nos aporta y poder medir el efecto de cualquier experimento." Este equipo aún está aprendiendo. Necesita la estructura. Acortar la daily scrum sin entender por qué existe sería un error.

Equipo B (nivel Ha inicial): "Sí, porque nunca usamos los 15 minutos completos". Este equipo está experimentando, pero sin criterio claro. Podría funcionar, pero también podrían estar perdiendo oportunidades de coordinación que no son evidentes hasta que causan problemas.

Equipo C (nivel Ha avanzado/Ri): "Observamos que en las últimas 8 daily scrums, completamos la sincronización en 5 minutos y el resto es silencio incómodo. Hemos identificado que usamos Slack de manera tan efectiva durante el día que llegamos a la daily ya sincronizados. Vamos a experimentar con syncs de 5 minutos durante dos sprints, pero si alguien señala un impedimento que necesite más coordinación, extendemos ese día o convocamos aparte. En la retrospectiva evaluaremos si perdimos algo".

La diferencia no está en la decisión (acortar o no), sino en el proceso para llegar a ella.

La pregunta que deberíamos hacer

En lugar de preguntar "¿Podemos cambiar esta práctica de scrum?", la pregunta más útil es: "¿Qué nos está tratando de enseñar esta incomodidad?".

Si la retrospectiva se siente como una pérdida de tiempo, el problema no es la retrospectiva. El problema es que probablemente no estamos siendo honestos en ella, o no estamos convirtiendo los insights en acciones reales, o no tenemos la autoridad para cambiar las cosas que identificamos como problemáticas.

Por tanto, antes de desechar las prácticas, pregúntate: ¿el problema es la práctica, o cómo la estamos ejecutando?

La línea invisible requiere honestidad

La línea entre adaptación inteligente y degeneración del marco existe, pero no es donde la mayoría de la gente piensa. No está en si tu daily dura 15 o 5 minutos. No está en si haces planning poker o no. No está siquiera en si sigues todos los eventos de scrum al pie de la letra.

La línea está en la honestidad intelectual.

¿Puedes explicar qué problema resolvía la práctica que estás cambiando? ¿Tienes evidencia de que no está funcionando? ¿Sabes cómo medirás si tu adaptación es mejor? ¿Estás dispuesto a volver atrás si los datos muestran que te equivocaste? Si la respuesta a estas cuatro preguntas es sí, probablemente estás en el lado correcto de la línea. Si la respuesta es "no necesitamos eso" o "perdemos mucho tiempo", probablemente has cruzado hacia el cargo cult al revés: un culto a la "flexibilidad" que es tan dogmático como el culto a las reglas.

Porque al final, como nos recordaron los comentarios en LinkedIn, ambos extremos son trampas. El dogmatismo que dice "nunca cambies nada" impide el aprendizaje. Pero el relativismo que dice "todo es adaptable" destruye el marco que hace posible ese aprendizaje.

La maestría está en saber cuándo cada uno aplica. Y esa sabiduría solo viene de una cosa: practicar, observar, reflexionar, adaptar. Es decir, empirismo. Es decir, scrum mismo.

Bibliografía

• Brière, Rémi (2025). "Agility and the Cargo Cult - Part 1". SensioLabs. https://sensiolabs.com/blog/2025/agility-and-the-cargo-cult-part-1
• Cockburn, A. (2006). Agile Software Development: The Cooperative Game (2nd ed.). Addison-Wesley Professional.
• Godesky, J. (2023). "The Scrum Cargo Cult". Medium. https://medium.com/@jason.godesky/the-scrum-cargo-cult-98def5b4af2f
• Johnson, D. (2024). "Scrum and Shu Ha Ri". The Pragmatic Agilists. https://medium.com/the-pragmatic-agilists/scrum-and-shu-ha-ri-10388faf52b4
• Management 3.0. (2022). Shu Ha Ri in Agile Leadership Explained. https://management30.com/blog/shu-ha-ri-agile-leadership/
• Oliver, A. C. (2013). "The cargo cult daily standup". Black Swan Farming. https://blackswanfarming.com/the-cargo-cult-daily-standup/
• Scrum Alliance.
  • (2011). The Art of Shu Ha Ri in Scrum. https://resources.scrumalliance.org/Article/art-shu-ha-ri-scrum
  • (2023). Your Guide to Empirical Process Control in Scrum Teams. https://resources.scrumalliance.org/Article/empirical-process-control-scrum
• Scrum.org.
  • The Three Pillars of Empiricism (Scrum). https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum
  • Shu-Ha-Ri of Professional Coaching. https://www.scrum.org/resources/blog/shu-ha-ri-professional-coaching
• Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org
• Sutherland, J., & Schwaber, K.
  • (2017). "The Creators of Scrum Update the Scrum Guide". Scrum.org. https://www.scrum.org/resources/creators-scrum-ken-schwaber-and-jeff-sutherland-update-scrum-guide-0
  • (2020). "Ken Schwaber and Dr. Jeff Sutherland Update the Scrum Guide on the 25th Anniversary of the Scrum Framework". Scrum.org. https://www.scrum.org/resources/ken-schwaber-and-dr-jeff-sutherland-update-scrum-guide-25th-anniversary-scrum-framework