Buscar en Gazafatonario IT

lunes, noviembre 29, 2021

La temible milla extra


Bien pude nombrar a este artículo como “En qué momento se jo$#ó el mundo laboral”, pero no quise llamar mucho la atención. Y es que esta así denominada característica del universo de la gestión organizacional “milla extra” se ha convertido en uno de los atributos más reconocidos del oscurantismo profesional en el que vivimos durante el siglo XX y parte de este nuevo milenio.

Tengo un interés significativo en el comportamiento humano, sobre todo en lo que tiene que ver con el trabajo colaborativo, el logro de objetivos, la alineación y la autogestión y la motivación laboral. En cualquier equipo, hay miembros influenciadores y, con frecuencia, observo a una persona en particular impulsando la consecución de resultados en el equipo. Estos seres extraordinarios son ejemplo de liderazgo, de servicio, de inspiración. Son ellos quienes dan esa “milla extra” que tanto anhelan las empresas, porque su comportamiento positivo impacta la dinámica y el desempeño de sus equipos y de la organización en general.

Sin embargo, la gran mayoría de las veces, estos individuos se encuentran en el otro lado de la fuerza, disfrazando o enmascarando su tipo de liderazgo e influencia. En mi experiencia, esta milla extra derivó en prácticas representativas de lo que me gusta llamar “la cultura del sacrificio”:

Extender el horario laboral hasta altas horas de la noche y los fines de semana.

Irse de la oficina más tarde que el jefe.

Salir a las 11 de la noche con el compromiso de regresar a las 6 de la mañana del día siguiente, no sin antes, cargarte de papelería y equipo portátil para “trabajar” hasta las 2 o 3 de la mañana.

No tener tiempo ni para ir al baño, mucho menos para tomar un almuerzo decente.

Estar impedido de asistir a las reuniones del colegio de los hijos debido a la fuerte carga laboral.

Asistir a reuniones, pero estar pendiente de otros temas durante esta e, incluso, trabajar en otras cosas mientras transcurre el evento.

Acumular tiempo de vacaciones, no tomar vacaciones o suspenderlas abruptamente debido a algo urgente en la oficina.

Excusarse por programar vacaciones con anticipación y decir que durante las vacaciones vas a estar atento a cualquier cosa que necesite tu equipo u otra persona de la empresa, que te pueden contactar en cualquier momento: incluso dejas nota con los teléfonos y formas de contacto de los familiares o amigos con quienes pasarás tus vacaciones.

Decir que la única manera de “ver”, de comunicarte con tus hijos y familiares es vía celular.

Practicar y fomentar la cultura de “envié el correo el día de ayer”, cuando en realidad lo enviaste a medianoche y querer respuestas y soluciones muy temprano en la mañana.

No “molestar” a tus superiores con problemas, en cambio, siempre llevarles soluciones.

Exigir resultados a tu equipo, simplemente con la visión de que esto los garantiza.

Trabajar bajo presión y con mucho estrés.

Ir a trabajar o hacerlo desde la casa cuando estás enfermo, es decir, cuando tienes descanso médico o te encuentras incapacitado por algún motivo de salud.

Y una extensa enumeración de propiedades que harían incansable esta publicación. En breve, la milla extra no es elegir cualquier camino y seguir caminando y marchando para salir del país de las “maravillas”. No se trata de dar más “horas nalga” a tu empresa solo para que vean lo “comprometido” que estás.

Así que mejor veamos un poco lo que queremos decir por “milla extra” y por personas que la practican y la promueven de una manera genuina.

La milla extra es:

Trabajar por una misión superior, por un propósito más allá de los intereses de las personas y de los equipos.

Exhibir comportamientos basados en valores y principios. Es decir, participar de equipos y organizaciones donde los valores sean el eje principal de convivencia y donde estos valores se definan, se demuestren, se demanden y se deleguen en conjunto, por todos los miembros del equipo.

Trabajar de manera colaborativa, aprovechando la inteligencia colectiva de los miembros del equipo.

Ambientar el escenario organizacional con comportamientos de seguridad sicológica, donde las personas se sientan protegidas y extraordinarias y con la plena convicción de que pueden dar lo mejor de sí mismas en beneficio de la empresa, de los clientes, pero también de los equipos y de ellas mismas.

Trabajar en pares, aprendiendo uno del otro y el otro del uno.

Liderar con el ejemplo.

Trabajar con una cultura de mejora continua, donde no tengas que pedirle permiso a nadie para mejorar.

Trabajar en un entorno con alto alineamiento, vía propósitos claros y precisos, pero también con un alto nivel de autonomía, con objetivos intermedios bien definidos y alcanzables en periodos cortos de tiempo.

Fomentar una cultura de "entrenamiento sin acompañamiento es una irresponsabilidad". Una cultura donde el mentoring sea algo común y corriente y no un plato especial que se prepara de vez en cuando, solo cuando sea posible contratar a un experto de fuera de la ciudad o del país.

Aumentar la cantidad de experimentos por unidad de tiempo. Abrir los espacios de aprendizaje y de innovación a todo el mundo en la organización.

Vivir bajo una cultura de comunicación a mansalva, cara a cara, donde el coraje, la confianza y el respeto se erigen como valores y pilares para el trabajo diario y para el logro de los objetivos propuestos.

Si eres un “líder de la milla extra”, es porque eres capaz de convertir la ansiedad de los miembros de tu equipo y de cualquier otra persona de la organización, en confianza en sí mismos y en los demás, y en aliento para ir más allá de los objetivos empresariales e impactar la forma de vida de los clientes y de todos en el ecosistema organizacional.

Y, por supuesto, muchísimas cosas más. Pero, como dije antes, no quiero hacer infinito este panegírico. Mejor te invito a que explores muchos de los artículos que he publicado en la última década en este mismo Gazafatonario.

Apostilla

Si tú y otras personas se sienten forzadas a gastar tiempo y energía en protegerse de los demás en la organización, eso la debilitará de una manera tal que será presa del entorno, muy pronto sufrirá consecuencias dramáticas y quizás desaparezca para siempre.

La ausencia de seguridad sicológica es como un cáncer: invisible, silencioso, mortal.

martes, noviembre 23, 2021

Scrumming the Scrum

Imagen de ar130405 en Pixabay
Acordemos esto de una vez: contrario a lo que muchos creen y hacen, las tareas más importantes durante un sprint deben ser las de tareas “Kaizen” o de mejoramiento continuo. Ahora bien, está claro que el objetivo del equipo en cada sprint es entregar valor, esto es, un incremento de producto con valor para el entorno bien sea el usuario, el cliente o consumidor, los interesados, los patrocinadores y, en general, el ecosistema organizacional. No perdamos eso de vista.

Pero muchos piensan que esto es lo único que se debe hacer durante un sprint. Es muy común llegar una retrospectiva y encontrar que las acciones de mejora definidas en la retrospectiva anterior e, incluso, en unas más antiguas no se han empezado a implementar o a adoptar. Las razones van desde el clásico “nos consumió el día a día”, hasta el “las tareas no se priorizaron”, “apareció algo más urgente”, “no tuvimos tiempo”, “tenemos mucho trabajo”, “eso no es urgente”, etcétera.

Es un círculo vicioso: no mejoramos porque no tenemos tiempo y no tenemos tiempo porque no mejoramos. Como siempre, hay que empezar por cambiar esa mentalidad, más que adicionar un proceso que las personas y los equipos necesitan aprender. La mejora continua no aumenta la carga de trabajo, no son más procesos ni herramientas, no se trata de más tiempo “improductivo”. Lo crítico es aprender a integrarla en nuestro trabajo diario.

El Kaizen es una forma de pensar y de hacer las cosas, no algo adicional por hacer. En la práctica, no son tareas para realizar los miércoles a las 9 de la noche o los domingos a las tres de la tarde, cuando se supone que ya “estamos al día” en las tareas habituales de la empresa. No. El kaizen hay que incluirlo como parte del valor que estamos produciendo para la organización. Es de esta manera cómo en el mediano y en el largo plazos seremos más productivos, más innovadores, avanzaremos más que la competencia, cubriremos las necesidades de nuestros clientes y nos adelantaremos a otras exigencias o problemas que tengan, seremos más creativos y disruptivos y podremos transformar no solo nuestra organización sino también el mercadeo que la rodea.

La lista de beneficios que obtenemos cuando adoptamos una mentalidad de mejoramiento continuo puede ser infinitita:

·       Personas más comprometidas y con tendencia a una menor rotación en la empresa

·       ¡Personas más felices!

·       Mejor servicio al cliente. No se nos olvide que estamos en la era de la hiperpersonalización de productos y servicios.

·       Productos y servicios más competitivos

·       Tener una cultura de aprendizaje proactiva

·       Operaciones más eficientes

·       Mayor productividad

·       Tiempos de entrega más cortos

·       Tasas de error más bajas

·       Mayor calidad

·       Mayor innovación

·       Costos más bajos

·       Mayor rentabilidad

·       Mejor ambiente de trabajo

·       Cambio de comportamientos hacia una cultura de colaboración y de innovación

·       Mejor experiencia del cliente

·       Mayor reputación de marca

Y un largo etcétera exponencial.

Hasta allí bien. ¿Y cómo lo hacemos?

Entra Scrumming the Scrum

Una de las múltiples formas de lograrlo, muy práctica por demás, es usar el patrón Scrumming the Scrum. Algo así como “aplícale Scrum a tu Scrum”, en el sentido de “mejora tu Scrum”. Si te ocurre lo que mencioné antes de “no tengo tiempo para mejorar” o de “no trabajamos en las acciones de mejora definidas en la anterior retrospectiva”, entonces este puede ser un buen comienzo.

Es simple: usa Scrum como una mejora del proceso. Es decir, aprovecha Scrum para cumplir o lograr tu visión de kaizen. Para ello necesitas tener retrospectivas efectivas. Como siempre, lo mejor de las retrospectivas ocurre una vez que estas finalizan, cuando empiezas a implementar las acciones que definiste con tu equipo para mejorar.

En la práctica te vas a enfrentar a situaciones como:

·       Bajo desempeño del equipo,

·       incapacidad de detectar y eliminar impedimentos,

·       poca o ninguna generación de Valor,

·       multitarea.

·       Estrés ocasionado por todo lo anterior. Y esto último es el inicio de una serie de eventos desafortunados que conducen a la mala calidad y, peor aún, a la desmotivación y al detrimento de la salud y de la energía de las personas del equipo.

Créeme, no quieres que nada de esto ocurra a tu alrededor. He estado allí, no se lo recomiendo a nadie.

1.    Empieza por realizar un análisis de cómo te fue a ti y a tu equipo en el último sprint en cuanto a personas y sus interacciones, procesos, herramientas y Definición de Terminado, entre otros aspectos. Esto es clásico en toda retrospectiva efectiva.

Siempre viene bien un análisis de causa raíz. Los cinco porqués son un buen instrumento para lograrlo. Pero también está el diagrama de espina de pescado de causa y efecto, también conocido como diagrama de Ishikawa. El método de las 5W + 2H también viene bien en estos casos. Incluso un diagrama de Árbol de causa – efecto, o la técnica de Pareto, en el que el 80 % del problema proviene del 20 % de las causas y El 80 % de las causas restantes solo afectó al 20 % del problema.

2.    Una vez establecida la causa raíz, usa algún tipo de técnica colaborativa para idear soluciones: tormenta de ideas y votación simple, voto de confianza, conversaciones poderosas o estructuras liberadoras, entre algunas otras. El objetivo es que, de una lista de acciones, iniciativas o experimentos, selecciones con tu equipo las que vayan mejor para la ocasión. Una matriz de Esfuerzo versus Impacto siempre viene bien en estos casos.

Advertencia: esto de encontrar la causa raíz y seleccionar la de máxima prioridad se convierte en un imperativo, es algo exigente, no subvalores la forma cómo lo haces. Si trabajas bien en esto y luego implementas la acción de mejora subyacente, verás un incremento inmediato en la productividad del equipo. Al contrario, si esto último no sucede, es que tú y tu equipo no están haciendo una exploración apropiada de lo que está sucediendo, no están usando una visión holística y por ello siguen sin entender ni encontrar la verdadera causa raíz del problema. Las cosas así, hazte acompañar de alguien con experiencia. 

3.    Selecciona una y sola una de las acciones de mejora de la lista anterior. De hecho, “un paso a la vez” es ya una acción de mejora en sí. Como dicen por allí, “el que mucho abarca, poco aprieta”. Puedes promover la práctica de iniciar con una de las acciones que requieren menor esfuerzo y que sean de alto impacto o valor para el equipo y la organización.

Advertencia: a estas alturas siempre estamos hacia el final de la retrospectiva, entonces tienden a presentarse algunas disfunciones como que dedicamos muy poco tiempo a pensar en cuál debería ser esa acción y tratamos de salir rápido con una votación simple sin mayor análisis del impacto que pueda tener. Si eres facilitador de equipos, Scrum Master, coach o mentor, trata de no promover estas “salidas” por la vía rápida.

Recomendación: considera representar o escribir la acción de mejora como una historia de usuario, sobre todo, con criterios de aceptación o con una lista de comportamientos o aspectos visibles una vez que la acción esté implementada o se haya adoptado por el grupo. He usado la técnica de hypothesis-driven development para escribir “historias de usuario kaizen” con muy buen resultado.

Por ejemplo, si uno de los problemas tuvo como causa raíz la falta de conocimiento y experiencia en el uso de historias de usuario como protocolo de comunicación dentro del equipo y con los usuarios o interesados, la historia de usuario de la imagen anterior nos ayuda con una hipótesis de valor: si asistimos a un curso de historias de usuario, obtendremos un resultado de valor; sabremos que la hipótesis es cierta cuando veamos la señal (medible) expuesta luego de la misma.

4.    En la siguiente Sprint Planning, haz visible esta acción Kaizen en el Sprint Backlog. Con el equipo, sitúa las actividades derivadas de la acción de mejora al inicio de la lista o en la cima de la pila de tareas.

Como siempre, ninguna de las tareas es la tarea de una persona, el sprint backlog es propiedad del equipo en pleno y las tareas kaizen no son la excepción.

5.    Como siempre, aunque quizás estas tareas kaizen no están orientadas hacia el logro del objetivo del sprint, merecen un apartado especial en la Daily Scrum. Así, el equipo completo revisa también cómo van hacia esa meta especial.

6.    Finalmente, junto al incremento de valor que inspeccionas en la Sprint Review, presenta los resultados sobre esta acción de mejora. A los invitados a la sesión seguramente les interesará saber que el equipo está mejorando gradualmente, paso a paso.

7.    Cualquiera que fuere el resultado de la implementación o adopción de la acción kaizen, analízalo en la siguiente retrospectiva. Lo ideal es que haya habido, al menos, un avance importante hacia la ejecución completa de la acción. Si no es así, considera revisar las prioridades del equipo y vuelve a empezar.

Para concluir

Es un hecho: vivimos en una era de cambios. Si tú y tu organización se encasillan en lo que saben y en lo que siempre les ha funcionado, muy pronto se quedarán atrás. Adoptar una mentalidad de mejora continua hará que tu equipo y tu empresa giren hacia una trayectoria diferente y más exitosa.


Para saber más de patrones

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 Scrumming the Scrum, 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.

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.