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.

Estimaciones en los tiempos de la agilidad

Presentación

Hace algunos días, mis amigas Valeria Vásquez y Alejandra García, un par de cómplices caleñas convencidas de esto de generar espacios para compartir conocimiento que nos permita cambiar, me invitaron al cierre de una iniciativa que decidieron liderar desde el día mundial de la Retrospectiva en 2019, la cual consistía en realizar reuniones virtuales abiertas sobre distintos temas seleccionados por la gente. Mi tema era precisamente este de las estimaciones. Aquí les presento algunas conclusiones, no sin antes felicitar en grande a estas dos intrépidas que se han tomado este asunto de ser líderes de una comunidad que sigue expandiéndose y creciendo y que cada día presenta nuevos retos, como lo es Ágiles Colombia.

Ahora sí, vamos a lo que nos ocupa.

Sobre estimaciones bajo el manto ágil

Decíamos en la reunión que una Estimación es un proceso analítico e imparcial para predecir la duración o el costo de un proyecto o desarrollo de producto, de una iniciativa en general. Y hacíamos énfasis en que la estimación es una predicción, no es una planificación, ¡no es un compromiso! Además, “una estimación es buena cuando quienes estimaron consideraron toda la información que tenían a su disposición para el momento y el propósito de la estimación”, o algo así nos contaba mi gran amigo Wilmar Hincapié en una conversación anterior.

Pero ¿qué es eso de “considerar toda la información” disponible? Bien, debemos considerar el entorno VUCA en el que nos movemos hoy día, donde la volatilidad, la incertidumbre, la complejidad y la ambigüedad están a la orden del día, en donde no es posible predecir o planear con absoluta certeza lo que vamos a entregar, cuándo lo vamos a entregar y cuánto será su costo. Lo que sí podemos hacer es empezar con planes iniciales, planes cuya elaboración no tome mucho tiempo y sobre los cuales haya certeza de que van a cambiar, quizás tanto como todos los días. Después de todo, la meta es entregar el mejor producto o servicio posible, no la planificación en sí y mucho menos la estimación. Es lo que hemos dado en llamar “filosofía ágil”. Más sobre esto en mi artículo “Cultura ágil: ese oscuro objeto del deseo”.

No estimamos en el universo de lo simple ni de lo complicado, sino en el entorno de lo complejo, de lo caótico y hasta del desorden (Cynefin). Por ello es que no existen las “buenas” técnicas de estimación ágil, aunque tampoco existen las malas, son simplemente técnicas, experimentos que hacemos para tratar de calmar el ansia de todos los interesados en temas como la duración de una iniciativa o en las fechas de entrega de producto.

Debemos deshacernos de una vez por todas y para siempre de las cadenas que nos impuso el triángulo de hierro de los proyectos tradicionales, ese que establecía el éxito de un proyecto si este se encontraba dentro de los límites de tiempo, alcance y costo estimados. En este orden de ideas los invito a que consideren mi enfoque integral de gestión de personas y desarrollo de productos (resultados y restricciones) que expongo en el triángulo ágil extendido.

Técnicas de Estimación

Sobre este asunto de las técnicas o experimentos para estimar también hablamos un poco.

1. Planning Poker

La experiencia nos ha enseñado a usarla cuando tenemos un número relativamente pequeño de elementos a estimar y con un equipo pequeño de personas. Más sobre esta técnica en https://www.mountaingoatsoftware.com/agile/planning-poker.

2. Tallas de camiseta

Esta es una técnica muy buena para estimar un backlog grande de producto. Especialmente cuando tenemos varios equipos concurrentes trabajando en el mismo producto. Es una manera informal y rápida de tener una idea aproximada del esfuerzo requerido para hacer algo. Para saber más sobre la técnica, accede a http://getskillsblogs.com/agile-estimation-with-t-shirt-sizes/.

3. Puntos de votación (dot voting)

Útil cuando nos enfrentamos a un conjunto relativamente pequeño de elementos y necesitamos una técnica súper simple y efectiva para estimar. El método se originó a partir de la toma de decisiones. Funciona bien tanto para equipos pequeños como para grandes, pero tenemos que limitar el número de elementos estimados. Más sobre la técnica en http://www.informit.com/articles/article.aspx?p=2117898&seqNum=3.

4. El sistema del cubo

Mucho más rápido que el planning poker es el sistema de cubos. Este sistema es una buena alternativa al estimar un gran número de elementos con un gran grupo de participantes. Más sobre este curioso método en:

http://www.agileadvice.com/2013/07/30/referenceinformation/agile-estimation-with-the-bucket-system/

5. Grande / Incierto / Pequeño

Un método muy rápido de estimación aproximada es el método Grande / Incierto / Pequeño. Se le pide al equipo que coloque los artículos en una de estas categorías. El primer paso es categorizar los elementos obvios en las dos categorías extremas (Grande y Pequeño). A continuación, el equipo puede discutir los elementos más complejos. Esto es en realidad una simplificación del sistema de cubos. El sistema es especialmente bueno para usar en equipos más pequeños con elementos comparables. Como siempre, podemos asignar tamaños numéricos a estas 3 categorías.

6. Mapeo de afinidad

Funciona mejor con un grupo pequeño de personas y un número relativamente pequeño de elementos. Más información sobre la técnica en:

http://www.gettingagile.com/2008/07/04/affinity-estimating-a-how-to/

7. Método de ordenamiento

Este es un ejercicio donde se obtiene una imagen precisa del tamaño relativo de los elementos. Funciona mejor con un pequeño grupo de expertos. Todos los elementos se ponen en orden aleatorio en una escala que va de “pequeña” a “grande”. A cada participante se le pide que mueva un elemento en la escala. Cada movimiento es solo un punto más bajo o uno más alto en la escala (muy pequeños, pequeños, medianos, grandes, muy grandes), o simplemente el participante cede el turno. Esto continúa hasta que ningún miembro del equipo quiera mover elementos o ceda su turno.

El método funciona mejor con un grupo relativamente pequeño de personas y una gran cantidad de elementos.

Más sobre una “buena” estimación

• Siempre demos un rango, nunca demos un número. Los números son para hechos, los rangos son para estimaciones
• Siempre preguntemos para qué serán usadas nuestras estimaciones. ¿A qué nos hemos comprometido? ¿Basados en qué información?
• La estimación es diferente de un compromiso. Realizar una estimación “errónea” no hace daño.
• Primero tratemos de medir, contar y calcular. Estimemos solo cuando sea necesario.
• Por sobre todas las cosas, ¡nunca negociemos las estimaciones! Siempre preguntemos las razones y los supuestos detrás de las estimaciones.

Juegos de estimación dañinos que debes evitar

La estimación es un juego pero evita los juegos de estimación dañinos:

• ¡Adivina el número que estoy pensando!
• ¡Un equipo increíble como el de ustedes puede hacer mucho más que esto!
• Esta vez será mucho más rápido porque hemos aprendido mucho del proyecto anterior.
• ¡Este proyecto será muy diferente!
• Si trabajamos un poco más duro, aumentaremos la velocidad.
• ¡Puedo programar esto en la mitad del tiempo! O el infame arte de hacer el doble de trabajo en la mitad del tiempo.
• Si bajamos la estimación, el proyecto se hará más rápido (esto realmente funciona en algunos escenarios).

Recomendaciones finales

• Si sigues estimando como hace dos años o más seguramente no eres  ágil, es más, quizás ni estés haciendo estimaciones propiamente dichas.
• Experimenta con muchos tipos de estimación. 
• Estimas trabajo de conocimiento, trabajo creativo, no trabajo predecible y repetitivo.
• Toma la estimación como un juego, un juego serio pero juego al fin y al cabo.
• Usa técnicas de estimación relativa.
• Con cautela, hazle caso a La ley de los grandes números.
• Fija objetivos y resultados clave (OKR), no números fríos.
• No estimes, a nivel de iteraciones, si no conoces la Definición de Terminado ni los criterios de aceptación.
• Cuando se trate de productos o de características de producto, estima en iteraciones o, a lo sumo, en días. Deja las horas para las actividades diarias.
• Estima para un rango que va desde la Mínima Entrega Viable hasta la Entrega Completa. Es decir, asegúrate de que en ese rango de tiempo harás una entrega de valor.
• Evita a los “influenciadores” expertos y, en general, a quienes pueden crear distractores al momento de realizar la estimación.
• Estima valor de negocio, no puntos de historia.
• Experimenta, crea tu propio método de estimación. Por ejemplo, el método 1 – 5 – 9 es una técnica simple que consiste en establecer si el elemento se puede elaborar o no en una iteración junto a otros 5 a 9 elementos. De ser afirmativo, es porque contamos con la suficiente información para desarrollarlo a continuación. Útil para usar durante la planificación de una iteración de menos de un mes de duración.
• ¡O simplemente no estimes del todo! Enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.