Quería compartir una pequeña anécdota que me pasó hace unos meses. Estaba trabajando con unos agilistas cuando teníamos de preparar una formación sobre Scrum para un grupo de mandos intermedios de una compañía. Durante la preparación debatimos sobre si durante el Sprint se podían aceptar o no cambios. La guía Scrum lo deja claro, pero el debate nos llevó a una duda ¿Qué bibliografía seguimos? ¡Aquí está el gran problema!
En Scrum existen dos concepto que son el “Scrum-but” y el “Scrum-and” que se refieren a la manera de usar Scrum por parte de los equipos. Ejemplos de Scrum-but:
- “Yo hago Scrum pero… a la retrospectiva el Product Owner no asiste porque está muy ocupado”.
- “Yo hago Scrum pero… hacemos un compromiso cerrado de las historias de usuario que vamos a entregar”
- “Yo hago Scrum pero… la Daily la hacemos solo los martes y los jueves”
Los Scrum-but ocurren habitualmente por varios motivos
Uno que he vivido personalmente es por desconocimiento, dado que hay tantas fuentes que hablan de Scrum y tantas formaciones que al final están existiendo muchos “Scrum”. Para un Scrum Master experimentado, el primer paso es conocer la guía, pero el siguiente paso es entender el porqué de cada elemento. Scrum está pensado para la entrega continua de valor a través de iteraciones de menos de 30 días. No entender bien eso es no ser capaz de explicar porqué un Product Owner debe ir a la retrospectiva o porqué la Daily son 15 minutos y es diaria.
Para conseguir esta interiorización, mi recomendación es leernos el libro “Scrum” de Jeff Sutherland que explica bastante bien el origen de Scrum y cómo favorece cada elemento de Scrum la inspección y la adaptación.
En este punto quería daros una regla personal: cuando discutas con alguien sobre una regla porque esa persona no está de acuerdo, entonces eso es un “scrum-but”. Un debate sobre las reglas en sí, es un debate muy pobre, entre otras cosas porque el objetivo de un equipo y menos aún de una organización no debe ser “hacer Scrum”. El objetivo es entregar valor y por tanto, el debate se debe de dirigir a cómo entregar valor a través de Scrum
“¿Por qué esta regla es así? ¿Cómo nos afecta a la entrega de valor el saltarnos la regla?”
En el ejemplo anterior, ¿por qué debemos permitir cambios en mitad del Sprint? Vamos a analizarlo, por un lado podemos argumentar que si permitimos eso podemos desfocalizar el equipo lo que supone ya no solo ir en contra de un valor de Scrum, sino que el equipo baje su productividad y con ello su entrega de valor. Sin embargo, en Scrum asumimos que el software emerge y que un cambio puede ser beneficio para alcanzar más valor. Por eso se crea el elemento “Sprint Goal”, que nos ayuda a decidir si un cambio es beneficioso o negativo y dependerá del objetivo para el cual realicemos este Sprint.
Por tanto, si eres Scrum Master, trata de entender e interiorizar bien la Scrum Guide y sobre todo el porqué de las cosas. Es la mejor manera de poder ayudar al equipo y a la organización a interiorizar Scrum como mecanismo de entrega de valor.
Por otro lado tenemos los Scrum-and, elementos que añaden valor a nuestro Scrum, es nuestra “manera de jugar”. Scrum se define como “ligero” porque deja pie a que podamos añadir prácticas, técnicas o herramientas que hagan que seamos lo más efectivos posibles.
Veamos algunos ejemplos de cosas que podemos añadir a nuestro Scrum:
- El Product Owner puede utilizar alguna técnica de detección de dependencias y para visualizar y gestionar las expectativas futuras como Release Plan o RoadMap.
- El Development Team pueden utilizar técnicas de desarrollo avanzado como TDD, pair programming etc.
- El Scrum Master puede utilizar para sus retrospectivas la técnica expuesta por Esther Derby y Diana Larsen.
Estos ejemplos de Scrum-and nos permiten un uso mejor de Scrum y potencian que el equipo obtenga un mejor resultado. Es importante no entender estas técnicas como una prescripción, por ejemplo, “todos los equipos deben usar un Plan de Releases”. Cada equipo debe de descubrir su camino y la libertad de decidir es la manera de conseguir aumentar la responsabilidad.
Por tanto, cuando debatas una práctica complementaria a Scrum piensa ¿viola alguna regla? ¿esa violación nos impide inspeccionar y adaptar y por tanto entregar valor? ¿nos ayuda a entregar mejor? Generalmente un Scrum-but ocurre porque la organización o nuestro contexto no lo permiten. Los Scrum-and empiezan a aparecer cuando hay equipos con alta motivación que entienden para qué sirve cada parte de Scrum y cuya misión es la entrega de valor. Estos equipos tratan de ir incorporando técnicas que les ayude en su camino, y no pierden el tiempo discutiendo reglas de Scrum con personas que no entienden lo que significa el empirismo y que el desarrollo de software es complejo.
Y tú ¿potencias Scrum o tratas de cambiarlo?
