“El
verdadero método de conocimiento es el experimento”.
-
[William
Blake. Poeta, pintor y grabador inglés.]
Muchos dicen usar Scrum,
dicen usarlo bien. Según los “lineamientos” ágiles, los he escuchado decir. Pero
he aquí una observación: la gran mayoría quizás ni lo están haciendo, a pesar
de los eventos, las responsabilidades y los artefactos. En general a casi todos
les hace falta lo que llamo “el espíritu de Scrum”. Ese que tiene que ver con
la teoría del marco de trabajo, con sus pilares y con sus valores.
Me concentraré específicamente en la teoría. En esa que
nos dice que Scrum se basa en el empirismo y en el pensamiento Lean. De hecho, mi
foco será esto del empirismo. Para empezar, es bueno reconocer que un entorno
empírico es aquel en el que la mejora y la dirección están guiadas por los experimentos
y la experiencia.
Esta última se basa en lo que ya ha ocurrido, en el
pasado. Muchos siguen usando Scrum tratando de predecir lo que va a pasar en el
futuro, a veces incluso, en un futuro distante. Nada más alejado de las
prácticas erróneas. Mi primera recomendación: usa la experiencia para
experimentar con la planificación en el muy corto plazo, la planificación de un
sprint; es más, con la planificación de un día de trabajo.
Para hacerlo, haz que tu equipo planifique teniendo en
cuenta lo que pasó en el último sprint. Quizás en los tres últimos. Tampoco te
vayas tan atrás. Seguramente hay cosas que han cambiado en el entorno. No es lo
mismo si hace unas semanas tu equipo estaba disperso por el mundo y apenas si
lograbas identificar un icono en una pantalla de alguna de las herramientas
favoritas de comunicación, a si en este momento están trabajando con un modelo
“híbrido” o presencial del todo. Mientras escribo esto, algunas empresas ya lo
están intentando.
Promueve un entorno donde todos en el equipo y los
interesados clave, además de los usuarios, esperen lo inesperado. Es lo que
sucede cuando trabajas bajo el manto de la incertidumbre y la volatilidad
inherentes a los escenarios que enfrentas habitualmente, sin hablar de la
complejidad propia del ADN de las iniciativas con las que convives a diario. Es
en estos escenarios donde un proceso empírico tiene vigor.
La
realidad del Scrum que haces
Todo el tiempo escuchas decir:
La mejor duración de sprint es de dos semanas. Pero ¿has
experimentado con otra duración? ¿Una mejor, por ejemplo?
En nuestras Daily Scrum seguimos usando las “tres
preguntas”. Nos parecen muy buenas. Sí, pero ¿has experimentado con otro tipo
de conversaciones?
Nuestra definición de terminado es muy completa. Pero ¿la
has mejorado con el tiempo?
En cada sprint implementamos entre 4 y 8 historias de
usuario. Pero ¿has experimentado con otros rangos?
Nos funciona bien un equipo de 8 personas. Pero ¿has ensayado
con otro tamaño de equipo?
Te haré otras preguntas:
¿Has dejado de usar la velocidad como medida de capacidad
para el equipo?
¿Sigues usando puntos de historia para estimar las
historias de usuario?
¿Has intentado con tu Product Owner alguna técnica
distinta a MoSCoW para ordenar el Product Backlog? ¿Has usado MoSCoW?
¿En realidad todos en el equipo y en el entorno, es
decir, interesados clave, patrocinadores y usuarios, entre otros, comparten no
solo la misma información sobre lo que está sucediendo, sino el mismo
significado de las cosas?
¿Has experimentado o has promovido cambios en la forma
como hacen la planificación del sprint, el refinamiento, la revisión o la misma
retrospectiva? Sobre esta última, ¿te limitas a los “pasos” generados por Retromat,
Fun retrospectives o el muy buen libro sobre el tema de mi gran amigo Jorge Abad, pero nunca has intentado crear tu propia retrospectiva, más adecuada a
las necesidades de tu equipo en un momento dado?
Finalmente, ¿te basas y promueves que el equipo y la
organización se basen en lo que ya ha sucedido, datos cuantitativos, sobre
todo, para tomar decisiones sobre qué hacer y cómo hacerlo en el futuro
inmediato?
Algo del
Scrum que deberías estar haciendo
¿Y por qué todo este cuestionamiento?
Bueno, precisamente porque Scrum es útil en un entorno donde
la experimentación debe(ría) estar a la orden del día. Como dije al principio,
a eso se refieren Schwaber y Sutherland cuando dicen que Scrum se basa, además
del pensamiento Lean, en el empirismo. Este último “afirma que el conocimiento
proviene de la experiencia y de la toma de decisiones con base en lo observado”.
Por ejemplo, no te desgastes mucho, ni entretengas a tu
equipo haciendo estimaciones, aunque sean “ágiles”, en el primer sprint.
Simplemente empieza. Al final del primer sprint tendrás un dato verificable de
cuánto hizo el equipo. De inmediato, en el segundo sprint, toma la decisión de
que la velocidad del equipo sea justamente el número de puntos que acaban de
lograr en el sprint anterior. De hecho, esto es un patrón Scrum conocido como El
clima de ayer.
Ahora bien, los experimentos no tienen que proponer
cambios sustanciales a lo que se está haciendo. Puedes usar mejoramiento
continuo de un paso a la vez, crea una expectativa de experimentación y mejora
bastante baja, de tal forma que para nadie sea una carga impositiva sino más
bien un camino a transitar, desafiante pero divertido. Eso sí, primero
enséñales a todos a mejorar, a proponer esos experimentos que tanto quieres.
Por ejemplo, enséñales a prepararse para una Daily
Scrum.
Puedo contar por centenares las reuniones diarias a las
que he asistido con personas que van muy mal preparadas a la misma. Todo el
tiempo están titubeando, desenfocados, desmotivados y mirando el reloj a que
simplemente terminen los infames 15 minutos de la reunión porque saben que eso
sí lo van a respetar. Una de las principales razones que he encontrado para que
esto suceda es que es una sesión subvalorada, a la que le dan poca o
ninguna importancia, porque no terminan de entender qué significa la inspección
y adaptación como pilares esenciales de un entorno empírico.
Lo he resuelto con entrenamiento, preparación y
acompañamiento. Además de crear todo un movimiento cultural alrededor del
evento:
1. Al
principio del sprint fijas una táctica o técnica para llevar a cabo la reunión.
2. Les
enseñas a todos en el equipo cómo será, haces una simulación. Llevas a cabo
conversaciones de mejora para que cada uno llegue a conocer muy bien los
detalles.
3. Antes
de las primeras sesiones, te aseguras de que todos efectivamente estén
preparados. Indagas si necesitan ayuda para estarlo. Les proporcionas la ayuda
que necesitan.
4. Durante
el evento estás atento a cómo lo llevan a cabo para, a continuación de este,
mantener otras conversaciones de mejora y perfeccionar en consecuencia.
5. Indaga
cómo se sienten, qué les hace falta, qué quieren proponer.
6. Precisamente
sobre este último asunto, lo más importante es, enséñales a mejorar ese paso a
la vez. Por ejemplo, enséñales con ejemplos claros a que cada vez digan más con
menos palabras. Pero sin atribularlos.
Por sobre todas las cosas, siempre ten en cuenta lo que
sucedió los días anteriores. Y haz que ellos en el equipo también lo tengan
presente. No puedes encontrar nada de eso que sucedió en un cuerpo de
conocimiento, mucho menos en la guía de Scrum. De hecho, Scrum se basa en la
inteligencia colectiva de las personas que lo usan. Y es precisamente esa
diversidad de perspectivas, una de las formas cómo enfrentamos la complejidad
que nos rodea, lo que posibilita que encontremos soluciones más acertadas o
apropiadas a los problemas que nos desafían cotidianamente.
Quieres
saber más
Para saber más del Scrum que deberías estar haciendo, te
invito a mi próximo curso para Scrum Masters. Encuentras toda la información de
este en:
https://luchosalazar.com/portfolio/nuevo-curso-scrum-master/
Mientras tanto:
Para saber más de cómo mejorar la Daily Scrum:
http://www.gazafatonarioit.com/2022/01/como-ayudar-tu-equipo-mejorar-su-daily.html
https://luchosalazar.com/2021/04/23/daily-scrum-kaizen/
Para saber más sobre el clima de ayer y otros patrones
Scrum:
https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/
