Scrum master: con el librito bajo el brazo

Realizaste el curso de Certified Scrum Master (CSM) y aprendiste sobre la Guía de Scrum. Pero cuando observas a tu equipo Scrum percibes diferencias que decides manifestar:

“¡Hey, según la Guía de Scrum debemos lograr un incremento de producto potencialmente entregable al final del Sprint, aquí solo hemos hecho el desarrollo y queda pendiente el testing para el siguiente Sprint!”

Una respuesta habitual es: “Ah, pero tu vienes con el librito de Scrum bajo el brazo, ¡Esto no es teoría, es el trabajo de verdad!” Una frase que también se suele conocer como “by the book”. Buscando implementar los conceptos al pie de la letra.

Esta suele ser una reacción habitual de resistencia al cambio, que busca desestimar la guía de Scrum y desacreditar el rol de Scrum Master en pos de la complacencia. ¿No será un mecanismo para evitar el esfuerzo que requiere aprender nuevas formas de trabajo?

Alguien iniciante en Scrum puede percibir las falencias más evidentes de una implementación, pero seguramente no comprenda la relevancia de cada elemento de Scrum, ni las consecuencias de ignorarlas. Puede que no tenga el convencimiento sobre los mismos ni los argumentos para justificar los cambios requeridos.

Es fácil entonces sucumbir ante tales acusaciones y pensar que ser un “purista de Scrum” es una falta de profesionalismo y creer que un Scrum “by the book” es idílico, inalcanzable, inaplicable para nuestra empresa, o que no vale la pena el esfuerzo.

Según la guía: Cada elemento del marco de trabajo tiene un propósito específico que es esencial para el valor general y los resultados obtenidos con Scrum. Cambiar el diseño o las ideas esenciales de Scrum, omitir elementos o no seguir las reglas de Scrum, oculta los problemas y limita los beneficios de Scrum, e incluso potencialmente lo vuelve inútil.

Sí. Hay un punto válido: alguien con poca experiencia en Scrum podría intentar forzar una implementación “by the book” sin entender el porqué de cada elemento y sin ser consciente de lo que es posible implementar hoy y de las particularidades de la organización.

No se trata de eso, para implementar Scrum se requiere experiencia y la guía se debe usar como el norte al que buscamos llegar para ir mejorando progresivamente.

¿Es la guía de Scrum una teoría idílica?

Con más de 10 años de experiencia implementando Scrum en organizaciones diversas, puedo asegurar que la Guía de Scrum es sumamente válida y útil.

Scrum ha venido evolucionando a partir de la práctica desde 1993, aplicando sus propios pilares (Inspección, adaptación y transparencia). Con lo cual es una solución altamente probada para problemas habituales en el desarrollo de soluciones en entornos complejos.

Muchos equipos creen implementar Scrum, pero ignoran los pilares, valores, artefactos, eventos o responsabilidades según se describen o tienen un concepto deformado. Sufren impedimentos conocidos que se resolverían si sólo siguieran el marco de trabajo Scrum tal cual se describe en la guía. Recuerda que sólo puedes disfrutar de todos los beneficios si lo aplicas acorde a la guía.

Cabe mencionar que Scrum es un marco de trabajo y no una metodología. Se encuentra incompleto por diseño. Es la estructura básica. Una implementación de Scrum debe basarse en dicha estructura para completar los vacíos, pero no alterar dicha estructura.

BONUS: 5 consideraciones para una adopción exitosa de Scrum

En línea con lo que venimos desarrollando en este artículo, te comparto 5 puntos a considerar para la adopción Scrum.

• Sé consciente de la forma de trabajo actual y traza un puente para ir avanzando progresivamente hacia una implementación de Scrum según la guía. Evita la discusión de si es o no es Scrum durante el proceso de aprendizaje y adopción.


• No permitas la complacencia de conformarnos con una implementación “adaptada a la realidad de nuestra organización”. Es justamente al revés, debemos cambiar la organización para implementar Scrum. Solo así podremos disfrutar de sus beneficios.


• La guía no es suficiente, se requiere expertise para guiar a la organización, a los equipos y sus integrantes en la adopción de las prácticas ágiles de la forma correcta. Si no tienes personas expertas considera contratarlas. “Scrum es simple, pero no es fácil”, debido a que conllevan un cambio cultural.


• Como se recomienda en LeSS, antes de escalar la adopción de Scrum para múltiples equipos trabajando sobre el mismo producto, es necesario dominar Scrum a nivel de equipos.


• Para el desarrollo de software: Scrum se basa en la adopción de prácticas de desarrollo ágil de software. Extreme Programming (XP) es una buena opción para esto. Sin atención a estás prácticas y a la excelencia técnica será muy difícil implementar Scrum.

Un ejemplo de adopción de Scrum

El siguiente es un caso habitual de adopción de Scrum en equipo de software: durante el primer Sprint una persona especialista en el negocio escribe la especificación de una funcionalidad. En el Sprint 2, alguien especialista en backend implementa los servicios necesarios en base a lo especificado, En el Sprint 3, quien es especialista en frontend crea la interfaz empleando los servicios desarrollados. En el Sprint 4 quien hace el testing encuentra defectos que son planificados para el Sprint 5. En este contexto completar una sola funcionalidad llevó el tiempo de cinco Sprints.

Esta situación, no es un camino de adopción de Scrum. Es desarrollo en cascada (Waterfall) usando terminología Scrum. Lamentablemente esto es tan común que se conoce como “Water-Scrum-Fall”. Esta situación no debería presentarse en ningún estadío de la implementación de Scrum.

En Scrum todas estas actividades ocurren en un mismo Sprint y las personas trabajan colaborativamente sin segmentación de responsabilidades (todo el equipo es responsable de todas las tareas).

¿Más ejemplos? Estos son otros casos habituales que indican una mala señal

• Son un equipo, pero cada persona está haciendo una tarea distinta.
• La Daily Scrum como reporte de estado para el SM u PO.
• SM o PO hacen tareas de PM (el equipo no se autoorganiza)
• Hay personas con responsabilidades distintas. ej: quien testea no desarrolla.
• Al final del Sprint las historias no están cerradas porque queda trabajo pendiente.
• Las historias son la especificación del trabajo a realizar.
• Se requiere de muchos equipos para completar una única funcionalidad.

Entonces ya sabes, implementa Scrum “by the book”, pero sé consciente cómo llegar allí. Cada paso es un aprendizaje que puede demandar tiempo y esfuerzo. La organización podrá ir aprovechando los beneficios incrementalmente con cada mejora.

Muchos éxitos en tu camino ágil.

Gracias a mis colegas Kleeres quienes me dieron su feedback.
Imagen de portada: https://unsplash.com/@roadtripwithraj

Escrito por:

Damián Buonamico

Mi propósito es ayudar a equipos y organizaciones a alcanzar agilidad como medio para el alto rendimiento, productividad, satisfacción y para generar mayor valor con trabajo de calidad.