Imagen
de Christine Schmidt en Pixabay
Dentro de lo más común en los escenarios de alta
incertidumbre, ambigüedad y volatilidad en los que trabajamos están las
interrupciones a nuestro trabajo diario. Mal manejadas, estas obstrucciones se
pueden convertir en un gran dolor de cabeza para la persona, para el equipo y
para la organización y, por consiguiente, para el cliente final.
Entre otras consecuencias no menos graves, tenemos la
pérdida de foco en lo que hacemos, con la consiguiente parálisis o alejamiento
del objetivo del sprint. Además, el estrés ocasionado por las intermisiones
puede llegar a ser contraproducente para la salud del producto, pero, más
crítico aún, para la salud de las personas.
Algunas investigaciones [1] muestran que la multitarea
ocasionada, entre otras cosas, por las interrupciones frecuentes en el trabajo,
te hace estúpido y lento, al tiempo que aumenta el estrés y acelera el
envejecimiento. Adicionalmente, la multitarea puede reducir la velocidad o el
ritmo de un equipo tanto como a nada.
Fui desarrollador de software durante diecisiete años y
sé bien que la multitarea siempre ha sido una parte inherente del desarrollo de
software y la experimenté como la principal fuente de interrupciones debido al
cambio continuo de tareas en los equipos de desarrollo de software.
Este trabajo implicaba para mí una combinación de tareas analíticas
y creativas, y requería de una carga significativa en mi “memoria de trabajo” y
en la toma de decisiones. Esto imponía una carga cognitiva que me hacía perder
el enfoque y la concentración mientras trabajaba, lo que afectaba mi
productividad. Perentorio.
Los invito a visitar este enlace, donde podrán ver de
manera gráfica y cómica a la vez, por qué no deberías interrumpir a un
programador cuando está haciendo su tarea:
https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/
Pero estas dificultades no son propias solo del
desarrollo de software. Como mencioné antes, todo trabajo bajo escenarios
VUCA/BANI está supeditado a tener tales aprietos. ¿Entonces, qué hacer con
estas interrupciones si son inherentes a nuestro trabajo?
Si estamos usando
Scrum, las demandas de distintas áreas, combinadas con la interferencia de la gerencia,
pueden causar una disfunción crónica en el equipo, fallas repetidas en sprints,
incumplimiento en fechas de lanzamiento e incluso fallas en la empresa. Muchas
veces un equipo Scrum sirve a muchos interesados, quienes compiten por la
atención del equipo.
Patrones Scrum
En Scrum hemos aprendido a usar patrones, estos son
modelos de comportamiento que nos ayudan a solucionar problemas comunes. Cada patrón describe un problema que ocurre una
y otra vez en nuestro entorno, y luego describe el núcleo de la solución
a ese problema, de tal manera que puedes usar esta solución un millón de
veces, sin hacerlo dos veces de la misma manera. O algo así nos enseñó Christopher
Alexander en su libro A Pattern Language. Alexander es conocido como el “padre
de los patrones”. Para conocer un poco más sobre esto puedes ver mi
presentación en:
https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/
Un patrón nos ayuda a explorar:
·
El problema, su naturaleza, la causa raíz. El
problema detrás del problema.
·
Las
fuerzas que interactúan que afectan el problema (que lo hacen difícil),
incomprensible a veces.
·
La
solución. Y por qué funciona esta solución. En qué condiciones funciona. Y
·
El
contexto resultante de aplicarlo en un escenario de la vida real.
illegitimus non-interruptus
A veces también
llamado el patrón del búfer de interrupción (Interrupt Buffer). Es un
hecho, cambiar las prioridades o los problemas en el campo a menudo
interrumpe el trabajo de los equipos Scrum durante un sprint.
En general, un equipo Scrum es un equipo o recurso comunitario que satisface las necesidades de muchas partes
interesadas. Además, es un recurso crítico para crear nuevos productos y
mantener productos existentes [2]. A menudo, la propiedad deficiente del
producto permite que las prioridades en competencia de una empresa
lleguen a un equipo Scrum. Por estas y muchas otras razones, un equipo Scrum
siempre está expuesto a interrupciones que obstaculizan la producción.
 |
| Figura
2: principales tipos de interrupción a un equipo |
Veamos esta solución
con un poco más de detalle…
1.
Lo
primero es tener una idea aproximada de cuanto esfuerzo o tiempo necesitamos
asignar al búfer. O sea, decidir el tamaño del búfer de interrupción en
el sprint backlog. Una revisión tipo “Clima de ayer” nos puede dar una
idea. Es decir, revisar qué tanto esfuerzo han requerido las interrupciones en
el sprint anterior o quizás un promedio de los últimos tres sprints.
En la figura a continuación vemos, como ejemplo, que
el búfer de interrupción se ha movido alrededor de los 7 puntos, tanto en el
sprint anterior, como en los tres últimos. De hecho, la gráfica muestra un
comportamiento similar en los últimos 7 sprints, pero esto es apenas una
casualidad. Quizás se trate de un equipo con una alta sinergia y que tiene un
histórico bastante bien conocido. Sin embargo, no es tan bueno considerar lo
que ha pasado durante tiempos más extensos, más allá de dos o tres sprints, ya
que las condiciones del equipo y del trabajo pueden haber cambiado de manera
considerable.
 |
| Figura 3: gráfico de la velocidad del equipo en los últimos sprints. Incluye búfer de interrupción. |
Entonces, aunque la velocidad del equipo, según la
gráfica histórica, es de alrededor de 27 puntos (usando también el promedio de
los tres últimos sprints), el equipo solo se comprometerá con 20 puntos de
historia y considerará un tamaño de búfer de 7 puntos.
2.
¿Y
entonces qué hacemos cuando se presenta una interrupción? Respuesta: todas las solicitudes
no triviales deben pasar por el Product Owner para su clasificación.
Es importante esto de lo “no trivial”. No se trata de que el Product Owner
“apruebe” todas las actividades no planeadas para el sprint. Pero sí las que
sabemos que pueden impactar en negativo el recorrido hacia el objetivo del
sprint.
 |
| Figura 4: comportamiento del búfer de interrupción en el sprint backlog. |
3. De manera natural vamos “midiendo” y evaluando el
“llenado” del búfer de interrupción. Es una actividad que debe inyectarse al
ADN del equipo, para que se haya sin mayores atribulaciones. Cuando el búfer se
“llene” y comience a desbordarse, es decir, el Product Owner o el equipo
pone un punto de más de los indicados en el búfer, el Scrum Team debe o
debería abortar el Sprint, no sin antes, hacer el análisis de
causa en una retrospectiva.
Lo que hemos comprobado es
que esta estrategia
ayudará al equipo a volver a planificar durante el Sprint para aumentar
las posibilidades de entregar el Incremento completo del producto. Ya
por lineamiento de Scrum habíamos aprendido que, durante el sprint, “el
alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende más”.
Recomendaciones
En la práctica, el búfer de interrupción puede ser un
porcentaje de tiempo. Por ejemplo, el 7 % del tiempo del sprint, el 10 %, el 14
%, etcétera.
¿Cuánto tiempo? ¿Cuál es el tamaño ideal del búfer de
interrupción? Esa es una cuestión cuya respuesta debe encontrar el equipo. Para
considerar: el objetivo de todo equipo Scrum es entregar valor (un incremento
de valor) al final de cada sprint.
Entonces, el foco del equipo debe estar en este aspecto: la entrega de
valor. Pero, incluso más importante, son las tareas o actividades “kaizen”,
sí, esas de mejoramiento, a las que también hay que dedicarles tiempo y
esfuerzo y con una prioridad máxima.
En general, debería
ser el Dueño del Producto quien equilibre el tamaño del búfer para no
descompensar la satisfacción del cliente en el corto plazo y mucho menos
disminuir la generación de ingresos para la organización. El objetivo de
todo Product Owner virtuoso es mantener con el equipo un tamaño de búfer
tal que no se impacte en negativo la entrega de valor.
Y no, las tareas de mejora continua (kaizen)
no son consideradas como “de interrupción”. De hecho, estas actividades
deben planificadas como las de mayor prioridad dentro de un sprint. De lo
contrario, ¿cómo aseguramos que el equipo mejore en el mediano y largo plazo?
¿Cómo aseguramos que en el futuro las cosas se hagan mejor y haya tiempo para
innovar o ser más disruptivos? (Ver en la imagen donde están estas tareas en el
Sprint Backlog).
Lo ideal es que el
búfer de interrupción tienda a no estar lleno, lo que permitirá que el equipo termine
temprano y avance desde el trabajo atrasado o trabaje para eliminar
los impedimentos. Y esto es primordial porque los equipos que terminan
temprano aceleran más rápido. Este es otro patrón Scrum cuya información,
por ahora, puedes revisar en:
https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/
Finalmente, si el
equipo usa el patrón el Clima de Ayer para dimensionar el búfer de
interrupción, como lo expliqué en el paso 1, entonces el búfer casi nunca se
llena y podemos empezar a pensar en reducir gradualmente su tamaño, lo que hará
desaparecer el problema de interrupción. Aunque en la práctica, quizás nunca
llegue a cero. Es lo que he experimentado.
Algunas referencias
[1] Darren Rowley and
Manfred Lange. “Forming to Performing: The Evolution of an Agile Team.” In Proceedings
of Agile 2007, Washington, D.C., 2007, pp. 408-414.
[2] Ver definición de Producto en la guía de Scrum.
Para conocer más de patrones Scrum, puedes ver esta
presentación y video: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/
En particular, para saber más del patrón Illegitimus
non interruptus, puedes mirar esta otra presentación:
https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/
El libro de los patrones Scrum, A Scrum Book, de Coplien, Sutherland y otros.
