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

domingo, noviembre 20, 2022

¡No entres en pánico! Sal del atascadero en el que está tu sprint con un procedimiento de emergencia

Vuelo 1549. Foto de Getty Images.

A nadie le gusta cuando un sprint se descarrila. Por ejemplo, es la mitad del sprint y comienzas a darte cuenta de que el equipo no podrá completar todo el trabajo al que se comprometieron y, lo que se suponía que iba a ser un período de intensa concentración y productividad, se ha convertido en una situación caótica y estresante. Si te encuentras en esta situación, ¡no entres en pánico! Hay una manera de volver a encarrilar las cosas.

Si eres piloto, ejecutas el procedimiento de emergencia específico para el problema en cuestión. Y eso es exactamente lo que debes hacer como Scrum Master o Agile Coach cuando te enfrentas a un sprint problemático. Esto te ayudará a retomar el rumbo y cumplir lo prometido. Al seguir este procedimiento, puedes identificar y abordar rápidamente cualquier problema que pueda estar impidiendo que tu equipo complete el trabajo pendiente del sprint y alcance el objetivo del sprint a tiempo.

Qué hacer cuando tu sprint se sale de los rieles

Muchas son las causas que se pueden manifestar cuando tu equipo está concentrado a su máxima efectividad y bloquear el trabajo u ocasionar desconcierto y desazón. Algunas de esas razones incluyen:

·       Planificación inadecuada

·       Requisitos emergentes

·       Problemas técnicos

·       Pérdida de personas o capacidades críticas

·       Capacidad sobreestimada (para esta puedes usar El clima de ayer)

·       Interrupciones no planificadas (usa Illegitimus non Interruptus o Búfer)

·       Trabajo anterior no terminado (utiliza la Definición de Terminado)

·       El Product Owner cambia lo planificado

·       Interferencia de la gerencia (usa Involucrar a la gerencia y MetaScrum)

En estos casos, primero, da un paso atrás y evalúa la situación. ¿Qué está causando el problema? ¿Es algo que se puede arreglar con una solución rápida? Si es así, implementa la solución alternativa y vuelve a encarrilar el sprint. Si el problema es más serio, es posible que debas hacer cosas más serias, por ejemplo, eliminar las tareas que ya no es posible terminar o no son necesarias y agregar nuevas tareas que se necesitan para lograr el objetivo del sprint. Pero, si todo lo demás falla, siempre puedes cancelar el sprint y comenzar de nuevo.

Hagas lo que hagas, no dejes que un sprint fuera de pista descarrile todo tu esfuerzo de desarrollo de productos. El procedimiento de emergencia Scrum está diseñado específicamente para este propósito. Veamos cómo funciona.

El procedimiento de emergencia de Scrum

1.    Cambiar la forma en que el equipo hace el trabajo. Hacer algo diferente.

2.    Obtenga ayuda, por lo general descargando el trabajo pendiente a otra persona.

3.    Reducir el alcance.

4.    Cancelar el sprint y volver a planificar.

5.    Informar a la gerencia cómo la emergencia afecta las fechas de liberación.

De todo esto, haz solo lo necesario para encarrilar al equipo y su trabajo. Y mucha atención: los equipos a menudo quieren reducir el alcance (opción 3) cuando encuentran dificultades. Pero los equipos tipo “Top Gun” (Lo mejor de lo mejor) encuentran una manera de ejecutar una estrategia diferente para lograr el objetivo del sprint. Eso sí, sé práctico: reducir el alcance antes de tiempo para que el equipo pueda terminar el trabajo planeado es mejor que caer en el fracaso.

Miremos más de cerca:

1.    Cambiar la forma en que el equipo hace el trabajo. Hacer algo diferente.

Si el equipo está acostumbrado a trabajar en sprints de dos semanas, intenta cambiarlo y hacer un sprint de una semana en su lugar. Puedes modificar el horario habitual en el que están trabajando o cambiar el lugar de trabajo por otro que de alguna manera permita energizar a las personas del equipo. El punto es que, a veces, todo lo que se necesita para volver a la normalidad es cambiar la forma en que se hacen las cosas.

Algo muy útil en estos casos puede ser atreverte a tomar ese camino que quizás tú y tu equipo han estado evitando: aplicar el patrón Enjambre, también conocido como Swarming o Flujo continuo de una pieza.

2.    Conseguir ayuda. Por lo general, descargando el trabajo pendiente a otra persona u otro equipo.

Si el equipo se siente abrumado, ¡pide ayuda! Esto podría significar descargar algunos de sus elementos pendientes a otro equipo o individuo que tenga capacidad. Recuerda: dar ayuda está muy bien, pero solicitar ayuda está mejor.

3.    Reducir el alcance.

Esto no tiene por qué ser algo terrible, ¡puede ser bastante liberador! Al reducir el alcance, estás dejando espacio para la creatividad y la flexibilidad dentro del sprint. Y a veces, eso es exactamente lo que se necesita para retomar el rumbo y lograr el éxito.

Aquí también puedes aplicar el patrón Equipos que terminan más temprano aceleran más rápido.

4.    Cancelar el Sprint y volver a planificar.

Puede llegar un momento en el que simplemente no sea posible salvar el sprint, en cuyo caso, cancelar y replanificar es la mejor opción. Esto no significa que se haya perdido toda esperanza, solo quiere decir que debes dar un paso atrás y reevaluar las prioridades del equipo y el objetivo para el próximo sprint.

5.    Informar a la gerencia cómo la emergencia afecta las fechas de liberación.

Una vez que hayas realizado (algunos de o todos) los pasos 1 a 4, es importante informar a la gerencia acerca de cómo estos cambios afectarán las fechas de lanzamiento. De esta manera, todos pueden ajustar sus expectativas en consecuencia y no habrá sorpresas en el futuro.

El poder humano de pensar y una breve historia de heroísmo

Esas cinco opciones pueden parecer una prescripción, algo tipo receta. No las tomes como tal. Las posibilidades son muchas. En cualquier caso, te dejo esta recomendación que doy desde hace más de dos décadas, cuando trabajaba con y fomentaba métodos más rígidos: cuando se trata de procesos y metodologías, no subestimes tu poder de pensar. Sentido común.

Así lo hizo el capitán Chesley Sullenberger cuando vio que su avión estaba perdiendo potencia y se dirigía hacia el río Hudson. Él supo que tenía que tomar medidas. Inmediatamente notificó a la torre de control y comenzó a seguir el procedimiento de emergencia. Gracias a su pensamiento rápido y a sus habilidades excelsas de pilotaje, pudo aterrizar el avión de manera segura en el río. Los 155 pasajeros a bordo sobrevivieron, gracias en parte a la cabeza fría del Capitán Sullenberger bajo presión. Hoy es un verdadero héroe y su experiencia es un recordatorio de que siempre debemos estar preparados para emergencias inesperadas.

Es inevitable que en algún momento durante tus sprints, te encuentres con problemas. ¡Está bien! Comprender cómo supervisar estos problemas es parte de ser un Scrum Master extraordinario. Es importante poder identificar el problema, crear un plan de acción y luego implementar ese plan en consecuencia. Como siempre, revisa y ajusta según sea necesario hasta que se resuelva el problema.

Al seguir el procedimiento de emergencia de Scrum, puedes volver a encarrilar tu sprint y evitar costosos retrasos, interrupciones mayores o incluso la baja anticipada del producto que tu equipo ha estado desarrollando con tanto esfuerzo. Así que la próxima vez que te enfrentes a un sprint problemático, no entres en pánico, simplemente toma el control, aplica algunos de estos pasos y podrás volver a la normalidad en poco tiempo.

¡Funciona para mí!

¿Quieres saber más sobre patrones Scrum?

Para conocer más sobre el patrón Procedimiento de Emergencia puedes ir a: https://scrumbook.org/product-organization-pattern-language/emergency-procedure.html

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/

Cuya segunda parte encuentras en: https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

Y en la sección Patrones Scrum y otros energizantes Scrum de nuestro libro Scrum: epítome de experiencias que encuentran en https://www.amazon.com/dp/B0BB7PW1QL

  

lunes, agosto 22, 2022

El costo de hacer multitarea

El costo de hacer multitarea

La gráfica es perentoria. Si estás en dos proyectos o iniciativas puedes perder hasta el 20 % solo por cambio de contexto o cambio (“switcheo”) entre tareas.

Si estás en 3 iniciativas, hasta el 40 %. Es decir, en realidad no estás asignado al 33 % en cada una, sino al 20 %.

De allí, los retrasos en las entregas. Y la mala calidad. Ni hablar de cuando estás en cuatro o cinco proyectos o iniciativas, algo que sigue siendo común en muchas empresas.

Algunos estudios además dicen que si las tareas con complejas, por ejemplo, tareas de desarrollo de software o, en general, trabajo de conocimiento, este tiempo puede ser mayor. Nos movemos en el universo de lo complejo, donde no hay relación directa entre la causa y la consecuencia y solo podemos saber cómo nos fue en retrospectiva.

El verdadero costo de la multitarea

Pero esto es lo que las organizaciones apenas alcanzar a ver, al menos, quienes están cambiando a enfoques ágiles para trabajar.

Sin embargo, el costo más grave, el verdadero costo de no tener foco en lo que se hace, es la salud de las personas. Y de eso casi nunca hay recuperación.

Investigaciones [1] muestran que “la multitarea te hace estúpido y lento, al tiempo que aumenta el estrés y acelera el envejecimiento”.

[*] 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.

Una investigación realizada en la Universidad de Stanford descubrió que la multitarea es menos productiva que hacer una sola cosa a la vez. Los investigadores también encontraron que las personas que son bombardeadas regularmente con varios flujos de información electrónica no pueden prestar atención, recordar información o cambiar de un trabajo a otro tan bien como aquellos que completan una tarea a la vez. [2]

Pero lo más crítico que mostró esta investigación es que, además de ralentizarte, la multitarea reduce tu coeficiente intelectual. Un estudio de la Universidad de Londres descubrió que los participantes que realizaban varias tareas a la vez durante tareas cognitivas experimentaron disminuciones en la puntuación de coeficiente intelectual similares a las que esperarían si hubieran fumado marihuana o se hubieran quedado despiertos toda la noche. Las caídas del coeficiente intelectual de 15 puntos para los hombres multitarea redujeron sus puntajes al rango promedio de un niño de 8 años. [2]

Incluso se presenta daño cerebral si haces multitarea. Un estudio de la Universidad de Sussex en el Reino Unido encontró que quienes realizan muchas tareas a la vez tenían menos densidad cerebral en la corteza cingulada anterior, una región responsable de la empatía, así como del control cognitivo y emocional.

Y hay más. La neurociencia es clara: estamos programados para ser monotarea. Un estudio encontró que solo el 2.5 % de las personas pueden realizar múltiples tareas de manera efectiva. Y cuando el resto de nosotros intentamos hacer dos actividades complejas simultáneamente, es simplemente una ilusión. [3]

Conclusión

Muchas veces te dicen que eres bueno y que por eso te van a dar más responsabilidad. Otras veces tú mismo lo asumes porque crees que es lo mejor. Pero no. Incluso hacer multitarea con cosas “sencillas” como hacer algo en el trabajo y estar mirando el celular y además hablando con el compañero de al lado en la oficina, puede ser muy dañino para tu salud, en ocasiones, de forma irreversible.

Así es que la próxima vez que estés ante la disyuntiva de estar en dos o más iniciativas a la vez, piénsalo. Y a quienes tienen la responsabilidad de formar y liderar equipos, también tengan en cuenta esta reflexión. El verdadero costo de la multitarea no es la pérdida de productividad, a veces invisible; es una baja substancial en la salud mental y física de las personas multifoco, una disminución que en muchas ocasiones es irrecuperable.

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] Multitasking Damages Your Brain And Career, New Studies Suggest.

https://www.forbes.com/sites/travisbradberry/2014/10/08/multitasking-damages-your-brain-and-career-new-studies-suggest/?sh=6cbca3956ee6

[3] Why Multitasking Is Bad for You.

https://time.com/4737286/multitasking-mental-health-stress-texting-depression/

 






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.