jueves, 21 de enero de 2021

¿Si un equipo llega limpio a la iteración IP puede incorporar nuevo trabajo?

Imagen del tema Innovation and Planning Iteration cortesía de © Scaled Agile, Inc.
La pregunta del titulo del post la hizo recientemente un equipo cuyo avance hacia sus objetivos del PI era excelente. Básicamente estaban diciéndome que terminarían en las iteraciones previstas todas sus historias de usuario a tiempo y cubrirían todos los objetivos, tanto los comprometidos como los no comprometidos. Entonces, ¿porqué no incorporar nuevo trabajo en la iteración IP (Innovation and Planning)?

La respuesta está en System Thinking: la entrega de valor, y en definitiva la predictibilidad, está a nivel de tren (ART), no a nivel de equipo, por tanto esa situación de "todo terminado" debe de producirse en todo caso a nivel del tren. Así que mi recomendación final, no la inicial porque no estaba preparado para esta pregunta, fue que se informaran sobre la situación del resto de equipos, y quizá descubrieran que otro equipo podría necesitar su ayuda. Así que nos preparamos para tratar el tema en el siguiente Scrum de Scrums (SoS).

El entendimiento que el tren es la unidad, y que lo equipos son los que lo componen, es un concepto que tarda en calar. En un equipo que era cuello de botella por las dependencias de otros con ellos, usaron la expresión "corriendo detrás del tren", expresión que es muy ilustrativa y que muestra de nuevo la dificultad que entraña incorporar la perspectiva sistémica en las personas de los trenes.

Otra perspectiva que trae claridad es la teoría de flujo; donde lo que se conoce como slack time, tiempo sobrante, puede ser lo mejor que le puede pasar al flujo, ya que lo equilibra y lo hace más predecible. En caso de un PI este tiempo proporciona suficiente margen de capacidad para permitir la cadencia. En otras palabras, para que el tren esté optimizado a veces es necesario que alguna de sus partes esté suboptimizada. Si pretendemos llenar de trabajo al 100% cada hueco de tiempo sobrante aparecerán bloqueos y cuellos de botella que penalizarán fuertemente al flujo; incorporar nuevo trabajo puede hacer descarrilar el tren.

Lo que propone Lean es utilizar este tiempo sobrante como herramienta para aumentar la eficiencia de equipos y tren, y mejorar los procesos subyacentes. Ese es justamente una de las intenciones en la parte de innovación propuesta en la iteración IP. Por tanto la respuesta es "no", por mucha tentación de incluir más trabajo que pueda haber.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

domingo, 17 de enero de 2021

¿Qué dinámica utilizar para definir acuerdos o principios que rijan el comportamiento de un equipo?

TRIZ
Para definir los principios de la Comunidad de Práctica de Liberating Structures en España preparamos una sesión basada en una estructura liberadora llamada TRIZ.

Esta estructura esta concebida para frenar actividades y comportamientos contraproducentes y abrir espacio a la innovación. La hackeamos (la modificamos) para producir nuestros principios y fue todo un éxito. Este hack, que quiero presentar en este post, permite definir principios y acuerdos en una situación de partida en la que un equipo o grupo no tiene historia previa y no ha colaborado apenas.

Meetup con la comunidad efectuando TRIZ, gracias a todos
Lo interesante de esta estructura liberadora es que parte de una situación que no queremos, aquella que es la peor situación posible a la que pudiéramos llegar, y eso resulta que nos resulta muy fácil de imaginar y representar.

El ser humano hace muchas asunciones y se engaña fácilmente a si mismo, con lo que buscar directamente aquello que quiere no siempre es fácil. Pero el ser humano es muy creativo describiendo lo que no quiere, así como para imaginar acciones que llevarían a esa situación. TRIZ define las acciones, en nuestro caso principios y acuerdos, como contramedida a las acciones no deseadas.

Visual recording de la sesión
¡Gracias Fco.Javier Pecci!
La preparación requiere 4 tableros:
  1. Peor resultado no deseado
  2. Todo lo que podemos hacer para lograr el resultado no deseado
  3. Elementos más relevantes del tablero anterior
  4. Acuerdos o acciones que nos lleven a evitar los elementos del tablero anterior
Y estos son los pasos y tiempos a ejecutar:
  1. Introducción al TRIZ hackeado e identificación de un resultado no deseado en un primer tablero. Los grupos pueden hacer una lluvia de ideas y escoger el resultado más indeseable (5 min).
  2. Cada grupo usa 1-2-4-All para hacer una primera lista de todo lo que puede hacer para asegurarse de lograr este resultado no deseado en el segundo tablero (10 min).
  3. Cada grupo usa 1-2-4-All para hacer una segunda lista en el tercer tablero con todo aquello de su primera lista que sea relevante. Una excelente opción es hacer una votación de hasta 3 elementos de la lista del segundo tablero y solo llevarnos los que se repitan (10 min).
  4. Cada grupo usa 1-2-4-All para determinar para cada elemento del tercer tablero qué acciones ayudarán a evitar esa situación no deseada y las recogerán en el cuarto tablero (10 min).
Finalmente los tableros 4 y 3 representan los principios o acuerdos, los que son y los que no respectivamente. Podéis encontrar aquí la información sobre TRIZ en inglés, y aquí TRIZ traducido.
Así quedó nuestra actividad, con un tablero inicial con los resultados y los 4 mencionados en el post
Quiero dar mis agradecimientos a Fede, Naty y Rogger por impulsar la comunidad y a Male y Gertru por compartir el diseño y la facilitación del evento conmigo :-)

martes, 5 de enero de 2021

¿Cuáles son las claves de los eventos del ciclo de Scrum?

En ocasiones algún neófito se dirige a mi como coach ágil y me pregunta por el sentido de los eventos de Scrum; si no son demasiados y quitan tiempo al equipo de desarrollo. Un clásico ¿verdad?, y sorprende que siga produciéndose esta clase de preguntas... Entonces respondo que se trata de los eventos de un ciclo rápido y cerrado de aprendizaje integrado para el desarrollo incremental de productos... Bueno, eso no es muy clarificador para el neófito, así que he elaborado el argumentario que me ayuda y quiero compartir en este post. 
Las claves de los cinco eventos del ciclo de Scrum
  • Planificación de sprint, el momento del compromiso: en este evento el equipo elabora el plan para las siguientes dos semanas (suponiendo sprints de dos semanas), un plan del que son propietarios y por tanto creen en él, en otras palabras se sienten comprometidos con su propio plan. Si desde fuera respetamos ese plan el equipo tendrá todos los números para cumplirlo.
  • Reunión diaria, el momento de la autoorganización: a lo largo del sprint este evento hace que los miembros del equipo se sincronicen y (auto)organicen diariamente su trabajo de forma colaborativa desde la perspectiva del equipo al completo.
  • Revisión de sprint, el momento de la entrega de valor y el feedback: Scrum, y la Agilidad en general, se focalizan en la entrega de valor; es en este evento donde se produce la entrega de valor a usuarios y clientes así como el feedback de los mismos. El feedback permite aprender sobre el producto que estamos creando y focalizar al equipo a lo largo de los sprints en las cosas de máximo valor en cada momento.
  • Retrospectiva, el momento de la mejora continua: este evento permite al equipo analizar como ha trabajado y se ha autoorganizado a lo largo del sprint recién acabado, y buscar una o varias acciones de mejora para evolucionar y crecer como equipo ganador.
  • Sprint, el contenedor con el ciclo de eventos para un ritmo sostenido para el desarrollo incremental: este evento contenedor de los demás define el ritmo con el que el equipo construye incrementos terminados al 100%, permitiendo así el aprendizaje sobre un producto deseable por nuestros clientes y que resuelva sus necesidades mediante la inspección y adaptación en cada ciclo.