Hace unos años, me encontraba dando una formación de Introducción a Agile&Scrum a un equipo. Durante la formación, un compañero me preguntó: “¿Cuántas reglas puedo saltarme en Scrum para seguir siendo Scrum?”. A pesar de la broma de la pregunta, realmente su intención venía por lo difícil que era aplicarlo, y más en ese momento de madurez de la organización.
Con el tiempo, he descubierto que existen dos debates en Scrum. Por un lado, el debate menos productivo sobre cómo modificar Scrum para evitar chocar con la organización. Aquí aparece el primer valor de Scrum, y es que saca a la luz deficiencias de la empresa. El otro debate, a mi juicio más interesante, sobre como complementar Scrum para entregar el máximo valor posible. ¡Estudiemos ambas aproximaciones!
¿Puedo saltarme reglas en Scrum?
Lo primero que debemos entender es que, en Scrum, no puedes modificar sus propias reglas. Los autores lo explicaron en el último párrafo de la guía Scrum:
“Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”
Scrum, es inmutable, y si lo modificamos podría funcionar, pero no es Scrum. Por tanto, la respuesta es evidente: no se puede modificar. Eso sí, en equipos y empresas que no son muy maduras en Scrum, podemos trazar un plan de implantación para ir introduciendo las reglas. Esto no es malo per sé, salvo que acabes creando equipos que no entregan valor por la ausencia de los elementos necesarios para inspeccionar y adaptar correctamente.
Scrum de manual: los pilares
Si pensamos construir un edificio, que representa a nuestro equipo y su capacidad de entregar valor, los pilares será Scrum de manual. Es decir, los pilares son inamovibles, y son lo que sostienen todo. Scrum de manual nos fija unas reglas, una manera de trabajar. Saber que tendremos una retrospectiva al final, nos permite aplazar debates para ese momento. El hecho de fijar una Sprint Review, nos permite entender cuándo analizaremos los resultados de nuestro trabajo.
Si solo nos quedamos con los pilares, no tendremos edificio. Podremos entregar valor, pero seguiremos lejos de obtener todo el potencial de Scrum. Esto es lo que se conoce como “Zombie Scrum” donde el equipo sigue las reglas sin pensar por sí mismo. Este Scrum no funciona, aunque puede ser necesario en equipo que arrancan en este marco para entender en qué consiste. Con el tiempo, el equipo debería madurar hacia su propia manera de jugar.
Tú configuración de Scrum: la primera planta
Un edificio siempre tendrá una primera planta. Esta primera planta representa nuestra configuración de Scrum, elementos que definen cómo vamos a jugar. Algunos ejemplos:
El tamaño del Sprint debe ajustarse a las necesidades del equipo y su negocio para poder entregar valor. Habrá equipos que puedan ir a Sprints semanales y otros mensuales. No debe existir una forma única de abordar el problema.
La hora del Daily Scrum debe decidirse en equipo. Se recomienda a primera hora del día, pero hay equipo que lo hacen antes de comer o por la tarde al conectarse equipos en otros horarios.
A pesar de que pueda haber una Definition of Done de la organización, cada equipo puede querer tener su propia más restrictiva. Esto habrá que tratarlo en equipo para que todos consensuemos que significa “terminado” en nuestro equipo.
La configuración del equipo depende de las skills que debamos cubrir para ser multidisciplinares. Esto es importante que lo hablemos y estudiemos si cubrimos todas ellas.
Hay equipos que tienen tableros físicos para organizarse y otros digitales. Además, la configuración de cada equipo puede ser única ya que debe potenciar la entrega de valor. Debatir sobre cómo organizaremos el trabajo es esencial.
Estos ejemplos representan diferentes maneras de “configurar” Scrum para entregar valor. Dependerá del contexto, del negocio, de las personas etc. El Scrum Master es quién debería sacar a relucir estos debates para que todos rememos en la misma dirección.
Complementando Scrum: el resto del edificio
El resto del edificio representa añadido que le queremos poner a nuestro equipo para potenciar su entrega de valor. Quizás queramos complementar nuestro Scrum Team con prácticas técnicas como pair programming o TDD. Estas técnicas nos permiten un mejor código para reducir fallos, dar mejor servicio y facilitar el mantenimiento del producto. ¡Bienvenidos!
Hay equipo que disponen de herramientas para que el Product Owner gestione el futuro del producto. Para ello podemos usar Impact Mapping o un Plan de Releases que nos ayude a pensar en lo que puede llegar a ser nuestro producto.
Las métricas de negocio son esenciales para potenciar la entrega de valor. No queremos hacer un producto, queremos generar valor a través de la construcción de un producto. Tener un debate lo que significa para nuestro equipo “valor” y definir métricas que nos digan si vamos en la buena dirección es clave para un equipo exitoso.
¿Qué se puede debatir?
Tener debates sobre los cimientos es lo que llamamos “Scrum-but”, hacer Scrum con excepciones. Esos debates no son muy productivos más allá de descubrir deficiencias en las organizaciones que tenemos que trabajar (tampoco es poca cosa). De hecho, ante un cambio de reglas, hay una pregunta clave: ¿cómo afecto esto a nuestra capacidad de entregar valor?
Los debates interesantes para mí son, la configuración de los equipos, y sobretodo los “scrum-and”. Los equipos que han conseguido complementar elementos a su Scrum para sacarle el máximo partido a su capacidad de entregar valor.
Y tú, ¿cambias reglas o complementas tu Scrum?
