Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Productividad. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Productividad. Mostrar todas las entradas

viernes, noviembre 12, 2021

illegitimus non-interruptus

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

Dada esa situación, lo que hacemos, siguiendo los lineamientos de este patrón es asignar explícitamente tiempo para las interrupciones y no permitimos más trabajo del que cabe dentro de la asignación. Ahora bien, si el trabajo excede la asignación (se desborda el búfer), podemos tomar la decisión de abortar el Sprint. Si el búfer se excede, es posible que tengamos un problema mayúsculo, uno cuya solución seguramente necesite del uso de otros patrones o de cambios en la estrategia actual de trabajo. Una estrategia inicial que se aplica en estos casos es cancelar o abortar el sprint.

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.