¿JIRA con BigPicture es una buena solución para PI Plannings remotas?

Una de las limitaciones de JIRA es que solo soporta planificaciones ágiles para un equipo a la vez. Para poder realizar PI Plannings en equipos que ya utilizan JIRA y permitir que éstos planifiquen de forma cruzada, en paralelo y fomentando la colaboración, una buena opción es la app BigPicture - Project Management & PPM de SoftwarePlant.

En su descripción podemos leer: "BigPicture es una gestión de productos compatible con SAFe®, que ofrece una colección de funciones para la planificación cruzada de equipos, mapeo de dependencias y gestión de riesgos", totalmente en la línea con una PI Planning. Aunque su ámbito es más extenso y pretende ser una capa de PPM: "Project Portfolio Management es la gestión centralizada de los procesos, métodos y tecnologías utilizadas por los jefes de proyecto y las PMOs para analizar y gestionar colectivamente los proyectos actuales o propuestos en función de numerosas características clave".

Al ser una app para JIRA la combinación incorpora todas las prestaciones propias de JIRA (elementos de las pilas, métricas, tableros, etc...), y eso la hace una buena opción de PI Planning para equipos que ya trabajen con JIRA. Para equipos que no utilicen JIRA recomiendo utilizar herramientas que no tengan ningún proceso por detrás y así permitir a los equipos descubrir su propio proceso antes de mecanizarlo: tableros físicos, Trello, etc.

En la web de SoftwarePlant podemos encontrar un artículo sobre como sería una PI Planning con BigPicture y JIRA: "How to do PI planning in Jira with SAFe in mind?", artículo que podemos encontrar traducido el blog de Deiser "Jira Software: ¿Cómo planificar PI respetando SAFe®?".

El artículo presenta algunos errores de concepto, por ejemplo en el paso 1 considera a los objetivos como inputs y no como ouputs, que es lo que son, objetivos alcanzables "cocinados" por los equipos durante la PI Planning. Por otro lado menciona en el paso 5 que puede ser que a lo largo del PI los equipos se den cuenta que no pueden completar todos los objetivos, cuando lo variable son las historias de usuario, no los objetivos. Los objetivos que se han comprometido en la PI Planning se han de cumplir si o si, ahora que un objetivo se puede cumplir con más o menos historias de usuario; imaginemos un caso en el que con una sola historia, de cinco identificadas, se da solución al 80% de la necesidad que origina el objetivo, eso probablemente sea suficiente para haber cumplido.

Program Board del video de SoftwarePlant BigPicture SAFe® webinar [Jira]

BigPicture puede ser una buena herramienta para cubrir las necesidades de una PI Plannings en remoto, la clave está en aplicar sus artefactos y sus flujos según los define SAFe.

Me he sumergido en el Program Board, el tablero de dependencias de BigPicture; este es un buena solución para que los equipos de un tren planifiquen de forma cruzada con JIRA, en este link podéis encontrar toda la documentación.

Las cosas que no me gustan básicamente son las heredadas de JIRA, como por ejemplo:

• La rigidez de jerarquía de pilas que alejan del pensamiento de cumplimiento por objetivos y focalizan en que el cumplimiento del 100% de los elementos del siguiente nivel de la pila; por ejemplo al considerar que un epic no está acabado hasta que el 100% de las historias de usuario asociadas no estén acabadas.
• El tablero de riesgos no clasifica según ROAM (Resolved, Owned, Accepted y Mitigated), sino va de leve a severo, con lo que se pierde el significado intrínseco de cada clasificación.

Pantallas del video de SoftwarePlant BigPicture SAFe® webinar [Jira]
Backlog, Program Board, Objetivos y Carga (por individuo a nivel atómico)

¿Qué tal PlanITpoker como herramienta de estimación colaborativa?

Los equipos ágiles dispersos necesitan poder estimar colaborativamente las historias de usuario con alguna herramienta virtual, y para ello una opción excelente es PlanITpoker, una herramienta totalmente gratuita, divertida y fácil de usar. Originalmente PlanITpoker se desarrolló en CodeFirst como una herramienta interna, pero vista la utilidad decidieron lanzar una versión disponible públicamente sin costo alguno y para toda la comunidad de desarrolladores ágiles.

Los jugadores votan cada historia de usuario usando cartas de estimación sin ver lo que otros jugadores están votando. Una vez todos hayan votado se destapan los resultados individuales y se discuten las estimaciones hasta llegar a un consenso. Al igual que en una actividad de planning poker presencial podemos revotar una historia después de la discusión y generar la consecuente transmisión de conocimiento.

El proceso de registro es rápido y sencillo, el único dato imprescindible es el nombre, aunque si queremos registrarnos podemos ingresar el email y subir una foto, en todo caso el acceso es instantáneo. Una vez dentro podemos crear varias salas para diferentes grupos de estimación. Estas salas son configurables, permite por ejemplo seleccionar diferentes tipos de cartas asociadas (serie de Fibonacci, serie de Cohn o Scrum, tallas de camisa y otras...), introducir la pila a estimar y configurar la forma en que se desarrolla la actividad de estimación.

Diversos pantallazos: 1.configuración, 2.estimación y 3.resultados

En definitiva es una herramienta excelente para realizar estimaciones con planning poker de forma remota, que fomenta estimaciones acertadas por su naturaleza colaborativa incluyendo todas las perspectivas, la transmisión de conocimiento y el compromiso compartido con el esfuerzo estimado por parte de todo el equipo.

Mi agradecimientos a CodeFirst poner a disponibilidad de todos esta herramienta de forma gratuita

¿Cuál es la novedad más importante de la Scrum Guide 2020?

Los compromisos - cortesía de Pixabay

Si le dices a la gente adónde ir, pero no cómo llegar, te sorprenderás con los resultados.

George S.Patton

George S.Patton hacía referencia con esta cita a los resultados de los escuadrones o squads: la unidad militar más pequeña que suele ser de entre 4 y 12 hombres, de composición heterogénea que está dotada para cumplir, por sus propios medios de forma aislada o en cooperación con otros escuadrones, un amplio abanico de misiones que van desde las de reconocimiento y seguridad hasta aquellas propias de la ofensiva y defensiva.

El squad son tus compañeros de equipo que te acompañan en una misión, una configuración muy similar a los equipos ágiles, y de hecho recordemos que el término "squad" es usual en algunas transformaciones basadas en el modelo de escalado de Spotify.

La cuestión para que los equipos de Scrum alineen su ejecución con la estrategia de la compañía y construyan soluciones excelentes, es ¿cómo generar una misión clara con la que se comprometa cada individuo y el equipo al completo? Ahí es donde la Scrum Guide impulsa la misión a través de la pila de producto y la nueva versión refuerza los compromisos hacía el alineamiento, el foco y la entrega de valor.

Los miembros de equipos de Scrum deben de sentirse comprometidos con aquello que se les ha propuesto o que les ha sido encomendado. Viven, planifican y reaccionan de forma acertada para conseguir sacar adelante sus objetivos.

Para que exista el compromiso es necesario que haya conocimiento, no podemos estar comprometidos a hacer algo si desconocemos los aspectos de ese compromiso y de las obligaciones que supone. Se suele considerar que una persona está realmente comprometida cuando actúa en pos de alcanzar objetivos por encima de lo que se espera, aunque luego no los supere.

La Scrum Guide pone énfasis en los siguientes 3 compromisos que todo miembro de equipo debe de entender y sentir:

• Objetivo del producto: necesitamos entender a grandes rasgos el todo del que participamos para entender donde encajamos y poder tomar buenas decisiones. El objetivo del producto, elemento que se introduce por primera vez en la nueva versión de la Scrum Guide 2020, le dice al equipo de Scrum a dónde ir. Así las historias de usuario van emergiendo en la pila de producto como elementos que harán que el producto evolucione y cumpla con el objetivo del mismo.
• Objetivo del sprint: queremos que el equipo de Scrum sea propietario de su plan y crea en él; el objetivo del sprint da el propósito del sprint y representa ese compromiso del equipo con lo que entregará a través de la pila de sprint.
• Definición de hecho: solo incrementos de producto que cumplan con los estándares de calidad crean un producto excelente. Productos que están cogidos con pinzas, aunque se comporten como esperamos, si no han sido construidos con calidad pueden derrumbarse a la mínima crisis. Por tanto necesitamos un claro compromiso hacia la calidad al 100% de cada pieza.

En Scrum queremos equipos comprometidos, que tomen excelentes decisiones y remuevan cielo y tierra ante los impedimentos que les desvíen de los objetivos de producto y sprint así como de la calidad.

Si le dices a la gente adónde ir, pero no cómo llegar, te sorprenderás con los resultados. - George S. Patton

---

Scrum Guide Noviembre 2020

Extractos de la Scrum Guide Noviembre 2020

"Cada artefacto contiene un compromiso para garantizar que proporciona información que mejora la transparencia y el enfoque con el que se puede medir el progreso:

• Para el trabajo pendiente del producto es el objetivo del producto.
• Para la pila de sprint es el objetivo del sprint.
• Para el incremento es la definición de hecho.

Estos compromisos existen para reforzar el empirismo y los valores de Scrum para el equipo de Scrum y sus partes interesadas."

Compromiso: Objetivo del producto

"El objetivo del producto describe un estado futuro del producto que puede servir como objetivo para el equipo de Scrum contra el cual planificar. El objetivo del producto se encuentra en el trabajo pendiente del producto. El resto del trabajo pendiente del producto surge para definir "qué" cumplirá el objetivo del producto.

Un producto es un vehículo para entregar valor. Tiene un límite claro, partes interesadas conocidas, usuarios o clientes bien definidos. Un producto podría ser un servicio, un producto físico o algo más abstracto.

El objetivo del producto es el objetivo a largo plazo para el equipo de Scrum. Deben cumplir (o abandonar) un objetivo antes de asumir el siguiente."

Compromiso: Objetivo del sprint

"El objetivo del sprint es el único objetivo para el sprint. Aunque el objetivo del sprint es un compromiso de los desarrolladores, proporciona flexibilidad en términos del trabajo exacto necesario para lograrlo. El objetivo del sprint también crea coherencia y enfoque, animando al equipo de Scrum a trabajar juntos en lugar de en iniciativas separadas.

El objetivo del sprint se crea durante el evento de la planificación del sprint y, a continuación, se agrega al trabajo pendiente de sprint. A medida que los desarrolladores trabajan durante el sprint, tienen en cuenta el objetivo del sprint. Si el trabajo resulta ser diferente de lo que esperaban, colaboran con el Propietario del Producto para negociar el alcance del trabajo pendiente de sprint dentro del sprint sin afectar al objetivo del sprint."

Compromiso: Definición de hecho

"La definición de hecho es una descripción formal del estado del incremento cuando cumple con las medidas de calidad requeridas para el producto.

En el momento en que un elemento de trabajo pendiente de producto cumple con la definición de hecho, se crea un incremento.

La definición de hecho crea transparencia al proporcionar a todos una comprensión compartida de qué trabajo se completó como parte del incremento. Si un elemento de trabajo pendiente de producto no cumple con la definición de hecho, no se puede liberar, ni siquiera presentar en la revisión de sprint. En su lugar, vuelve al trabajo pendiente del producto para su consideración futura.

Si la definición de hecho para un incremento forma parte de los estándares de la organización, todos los equipos de Scrum deben seguirla como mínimo. Si no es un estándar organizativo, el equipo de Scrum debe crear una definición de hecho adecuada para el producto.

Los desarrolladores deben ajustarse a la definición de hecho. Si hay varios equipos de Scrum trabajando juntos en un producto, deben definir y cumplir mutuamente con la misma definición de hecho."

¿Existe una dinámica para experimentar las ventajas de lotes pequeños?

The Coin Game, thanks to Solutioneers

Cuando aplicamos Lean una forma de reducir el WIP y mejorar el flujo es disminuir el tamaño de los lotes de trabajo que recorren la cadena de valor de construcción del software; desde la hipótesis de nuevas funcionalidades, a la integración, el despliegue y hasta el lanzamiento al mercado. Resulta que los lotes pequeños pasan por el sistema más rápidamente y con menos variabilidad, lo que fomenta un aprendizaje más rápido.

Un juego muy extendido que demuestra las ventajas de los lotes pequeños es "Pasar las Monedas", un juego en el que los participantes experimentan voltear diferentes lotes de monedas pasándolas de jugador en jugador para tomar los distintos tiempos.

Originalmente este juego, que es muy popular en formaciones de Lean y de Kanban, se efectuaba con 20 monedas; ahora gracias a Solutioneers tenemos a disposición una opción de juego on-line multijugador que ilustra muy bien las ventajas de los lotes pequeños. Lo hemos probado y quería mostrar a través de este post qué tal nos fue.

El juego consiste en 4 ciclos para experimentar y comparar los resultados de 4 diferentes lotes; 20, 10, 5 y 2. Los discos, que pueden ser negros o blancos, representan cara o cruz de monedas virtuales, si se clica en una moneda negra esta se volteará y se volverá blanca, y viceversa. Para mover el lote de monedas volteadas al siguiente jugador hay que clicar en el botón "Mover lote al siguiente jugador".

Pantallazos del aspecto del juego en plena simulación - gracias a los SAFers por la partida :-)

Uno de los aspectos más interesantes de este juego es que los temporizadores, los del cliente y los de los jugadores, se inician y paran automáticamente, por tanto no hace falta un cronometrador y los resultados se calculan de forma automática.

Tabla con los resultados del juego

A la izquierda podemos ver los resultados de nuestro juego: 25,67 segundos para los lotes de 2 monedas frente a los 49,43 segundos del lote de 20 monedas, números muy reveladores. Volteamos y pasamos la misma cantidad de monedas en ¡la mitad de tiempo!

Y lo que es más importante todavía, con un lote de 2 monedas nuestro cliente recibe las primeras monedas al cabo de 6,46 segundos... el Lead Time se ha acercado drásticamente al Cycle Time, hemos pasado de ¡49,43 segundos a 6,46 segundos!

Con lotes pequeños entregamos por primera vez en un momento muy temprano, momento en el que podemos tener importantes aprendizajes sobre nuestro proyecto, por no hablar de la facilidad de incorporación de cambios que permite.

Os invito a probar este juego, es muy clarificante. Para los que quieran intentarlo os dejo aquí el link a la guía del facilitador. ¡Mucho éxito!

¿Cómo crear una oficina virtual para impulsar la colaboración de los equipos?

Estamos en tiempos en los que nuestros miembros de equipo están dispersos en sus casas y nuestros eventos se producen habitualmente de forma remota. Algunos equipos ya estaban constituidos antes de COVID-19, y otros se han formado en plena pandemia. Necesitamos coaches ágiles y todas las herramientas posibles para crear alineación y aceleración rápidamente, recursos para establecer relaciones de confianza incluso cuando los miembros de los equipos nunca se hayan conocido en persona.

Una de las características de la nueva realidad es la soledad entre los miembros del equipo, crear el espíritu de equipo y sentimiento de pertenencia al mismo es un reto que requiere nuestra atención. Jurgen De Smet me ha hablado de Sococo, una aplicación que proporciona una oficina virtual que fomenta que los individuos remotos se sientan conectados e involucrados, así que quiero dedicar este post a esta solución cloud de lugar de trabajo virtual.

Sococo es una herramienta que proporciona un mapa visual de la oficina virtual en la que se visualizan todos los individuos y por el que éstos pueden moverse libremente. Para brindar transparencia a los equipos, permanecer conectados y colaborar, Sococo proporciona a cada uno un avatar, su ubicación y un estado para representar por ejemplo si está en una reunión, si está o no disponible, si está sin conexión, etc.

Las salas de la oficina virtual brindan videoconferencia, llamadas de voz, mensajería chat, tanto entre todos los asistentes como de uno a uno, y también la posibilidad de compartir contenido y pantallas sin necesidad de software de terceros. Una sala tiene todas las herramientas que maximizan la colaboración en los equipos y asistentes a las reuniones. Dado que la oficina virtual con sus salas y sus individuos están a la vista se produce la colaboración espontánea; podemos pasar a saludar a nuestros compañeros o sumarnos a una reunión y poner manos a la obra.

Ver a los demás moverse por la oficina, mientras interactúan como si estuvieran todos en el mismo edificio, es un recordatorio constante de que somos un equipo y no estamos solos. En cualquiera momento podemos pasar el rato en la máquina de café, tener una charla de pasillo con un compañero o asistir a almuerzos del equipo y otras actividades de team-building virtuales.

Quiero compartir una anécdota de Jurgen para ilustrar como Sococo fomenta esas relaciones de confianza que crean ese espíritu de equipo que hace que el equipo sea más que la suma de los individuos. Ocurrió en tiempos anteriores de COVID-19, donde los equipos estaban distribuidos en diferentes países: Un holandés y un hindú, ambos en la sala del vending de sus respectivas oficinas de su país, estaban tomando café a la vez y hablando sobre sus familias a través de la videoconferencia de Sococo en sus móviles. ¡Ese s el comportamiento que ocurre en miembros de un equipo ágil!

Oficina virtual de ejemplo de la web de Sococo

¿Tablero de dependencias o de compromisos?

Tablero de compromisos donde los equipos ágiles y de soporte (TI y negocio)
colaboran para alinear y priorizar iniciativas a realizar hasta finales de año,
del video resumen del 2do PI Planning de Telefónica del Perú

Mientras miraba el video resumen del 2do PI Planning de Telefónica del Perú me llamó mucho la atención la imagen de la derecha que se muestra en el segundo 0:20. Se trata sin duda de un tablero de dependencias de una tribu en cuya cabecera puede leerse "Tablero de compromisos"...

¡Qué acierto! pensé, ese título va a la esencia, un tablero que representa los compromisos cruzados que adquieren los equipos en la PI Planning. Realza de esta manera que un tablero de dependencias no trata solo de visibilizar las dependencias identificadas, también trata de visibilizar el compromiso adquirido en cada una de estas.

Recordemos que para que un elemento con dependencias se lleve al tablero de dependencias tiene que haber sido hablado con el equipo del que dependemos, y haber sido resuelta su dependencia: haremos tal actividad en un sprint acordado para que el equipo dependiente pueda desarrollar su trabajo en un sprint posterior sin bloqueos ni retrasos.

El compromiso resultante se hace patente con la regla de que sólo un miembro del equipo correspondiente puede colocar un elemento en su carril, está prohibido colocar cualquier cosa en el carril de otro equipo. Con esto nos aseguramos que haya verdadero compromiso, si yo coloco algo en mi carril es que lo hago de forma consciente y entendiendo las consecuencias.

Utilizar el término tablero de compromisos tiene otra ventaja, y es que resuelve la problemática entre dependencias no resueltas y riesgos. Una dependencias no resuelta es un riesgo, y dado que en una PI Planning tenemos tablero de dependencias y tablero de riesgos puede resultar confuso distinguir riesgos y dependencias.

Para futuras PI Plannings hablaré de compromisos en lugar de dependencias... :-)

¿Cómo se sincroniza Product Management en SAFe®?

PO-Sync como evento del ART - imagen del tema
Program Increment cortesía de © Scaled Agile, Inc.

SAFe® introduce en la sincronización del tren (ART), en la llamada ART-Sync, el evento de PO-Sync. Su objetivo principal es obtener visibilidad sobre el avance del tren en la construcción del producto y del progreso hacia los objetivos, discutir problemas u oportunidades en el desarrollo de las features y evaluar cualquier ajuste de alcance del PI para asegurar una alineación de la visión del producto y el contenido relacionado con el trabajo en todos los equipos involucrados.

Este evento suele ocurrir semanalmente o con mayor frecuencia, según sea necesario, y está limitado a un tiempo determinado de 30/60 minutos. Cada equipo envía a su Propietario del Producto al PO-Sync y todos los Product Managers deben de asistir, lo suele facilitar el RTE o un Product Manager.

PO-Sync ante el Program Board
cortesía de Pixabay

Se efectúa ante el Program Board para dar visibilidad holística de la situación del tren, y se discuten temas en los que se incluyen:

• Hacer seguimiento de features, progreso de los equipos e interoperabilidad.
• Actualizar las dependencias y evaluar si el plan se ve afectado.
• Actualizar los riesgos no resueltos, tratar los que puedan haber aparecido recientemente y evaluar si el plan se ve afectado.
• Analizar problemas y oportunidades surgidas con el desarrollo de las features/epics.
• Evaluar posibles ajustes de alcance, calendario y/o de prioridad (basados en realidades de los equipos y necesidades de los clientes).
• Actualizar el tablero Kanban del tren.
• Tratar otras cosas relevantes para compartir, como por ejemplo releases.

En un tren que esté empezando vale la pena verificar las siguientes preguntas con cada Propietario del Producto:

• ¿Está claro el rol del Propietario del Producto?
• ¿Están ocurriendo los eventos (planificación - reunión diaria - revisión - retrospectiva) con el equipo?
• ¿En qué historias de usuario está trabajando el equipo en esta iteración?
• ¿Cómo se está preparando el contenido para las próximas iteraciones?
• ¿Algún problema u oportunidad abordados por el equipo?

A PO-Sync generalmente le sigue un "Meet After", o reunión posterior, para aquellos que deseen profundizar en problemas específicos.

El evento también se puede utilizar para preparar el próximo PI y puede incluir el refinamiento de la pila del programa y su priorización mediante WSJF (Weighted Shortest Job First).

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

¿Una actividad de team-building que asiente la colaboración en equipos remotos?

Tangram casa resuelto - cortesía de Pixabay

En esta época de COVID-19 es más importante que nunca hacer actividades de team-buidling, tanto para formar equipos vía remota como para reforzar equipos existentes. Toda actividad de team-building refuerza la integración de los miembros del equipo, muestra las debilidades y fortalezas de cada individuo en relación al equipo e impulsa el progreso a lo largo de las etapas de Tuckman.

Quiero presentar una actividad muy sencilla y que se realiza en menos de media hora. Se basa en Tangram (siete tableros de astucia), un juego chino muy antiguo, que consiste en formar figuras con siete piezas, llamadas Tans, sin solaparlas: 5 triángulos, 1 cuadrado y 1 romboide.

El propósito de esta actividad es experimentar cómo funciona un equipo ágil en los aspectos de colaboración y comunicación.

Pantallazos antes y después de la actividad que comparto en forma de Google Slides en este post

Los pasos para realizar el juego son:

1. Seleccionad un cronometrador
2. Resolved en tres iteraciones de forma colaborativa los rompecabezas lo más rápido posible con un tiempo límite de 3 minutos
3. Después de cada figura haced una retrospectiva de 1 minuto para discutir el proceso e identificar cómo podéis mejorar
4. Pasad a la siguiente figura y aplicad las mejoras identificadas
5. En la retrospectiva final comparad los tiempos de cada iteración y compartid los aprendizajes

Segunda ronda en ejecución

Sigue un ejemplo del aprendizaje de un equipo que trata de resolver los rompecabezas de forma colaborativa:

• La primera ronda suele ser caótica, todo el mundo se lanza a resolver el rompecabezas de forma individual; chocan en la selección de los Tans y algunos deshacen lo que otros hicieron.
• En la primera retrospectiva el equipo se focaliza en como mover las fichas, en como decir donde van y quien mueve. Suele aparecer la figura del facilitador que mueve y comparte una pantalla que sirve de referencia para las conversaciones.
• A lo largo de la segunda ronda se producen principalmente conversaciones sobre como mover las fichas, hay menos jugadores moviendo y se ve claramente como cooperan.
• En la segunda retrospectiva aparecen las primeras reglas, como por ejemplo empezar con piezas que sea evidente donde van.
• La tercera ronda ya es de equipo integrado, las conversaciones son muy cortas y se producen indicaciones rápidas de forma ordenada.
• En retrospectiva final he oído la frase "lo difícil es llegar a una estrategia común", y eso es precisamente el objetivo de este ejercicio; aprender a ser equipo definiendo una estrategia común.

Observaremos que la resolución de los rompecabezas suele empezar con alrededor de los 2 minutos, y el último rompecabezas, que es de un nivel más avanzado, ¡lo resuelven en más o menos 1 minuto!

Tangram on-line de Mathigon

He creado un documento en formato Google Slides que permite que varios participantes colaboren sobre el mismo y resuelvan el rompecabezas. Si sigues este link a Google Drive te abrirá a una copia que podrás guardar en tu unidad:

"TANGRAM: Una actividad de team-building"

Otra opción para realizar la actividad es el Tangram on-line de Mathigon, el de la imagen que se ve a la izquierda. Cada sesión es para un solo jugador y la idea es que un jugador voluntario comparta su pantalla en videoconferencia y haga los movimientos que el equipo decida hacer.

A través de esta actividad también podéis hacer experimentar la autoorganización y la mejora continua de los equipos ágiles a vuestros alumnos en los cursos de Scrum. ¡Mucho éxito!

¿Cómo sincroniza Scrum de Scrums el ART en SAFe®?

Scrum de Scrums como evento del ART - imagen del tema
Program Increment cortesía de © Scaled Agile, Inc.

SAFe® introduce en la sincronización del tren (ART), en la llamada ART-Sync, el evento de Scrum de Scrums. Su objetivo es apoyar a los equipos en la colaboración y coordinación de su trabajo con otros equipos, coordinando las dependencias del tren y proporcionando visibilidad del progreso y los impedimentos, para asegurarnos de que logren sus objetivos de sprint versus a los objetivos generales del PI.

Scrum de Scrums suele ocurrir una vez a la semana. Dependiendo de la madurez es usual que al principio se realice con mayor frecuencia, e incluso haya algún evento ad-hoc provocado por una situación urgente o circunstancias particulares.

Se realiza dentro de un tiempo limitado, usualmente a 30 minutos, y de nuevo, dependiendo la madurez si queremos apoyar el aprendizaje, puede ser positivo alargar y limitar los primeros eventos a 60 minutos. Lo facilita el Release Train Engineer (RTE) y asisten los Scrum Masters, y opcionalmente miembros de equipos, incluidos Propietarios del Producto, como expertos para tratar algún impedimento o necesidad que el equipo ha llevado al Scrum de Scrums. La asistencia es obligatoria, por tanto es importante agendar el evento en un slot que todos puedan asistir, especialmente ahora con COVID-19 y nuestra realidad de equipos dispersos cuando es importante buscar una hora que ayude a todos.

Scrum de Scrums ante el Program Board

Se efectúa ante el Program Board para dar visibilidad holística de la situación del tren, y el RTE sigue el un guión de preguntas para facilitar la sincronización. Quiero resaltar que los Scrum Masters, o quienes representen su equipo, deben haberse preparado para responder a estas preguntas previamente.

• ¿Qué hizo mi equipo para lograr su objetivo del sprint y PI desde la última reunión ?
• ¿Qué hará mi equipo para lograr su objetivo del sprint y PI desde ahora hasta la siguiente reunión?
• ¿Hay algún impedimento que esté afectando a mi equipo y que impacte en su objetivo del sprint y PI?
• ¿Hay algo de mi equipo que se pueda interponer o afectar al los objetivos del sprint y PI de los demás equipos?

Mantener la reunión breve y enfocada en estas preguntas ayudará a concentrarse en lo que realmente importa, y al RTE a estar al tanto de los problemas que afecten a más de un equipo.

A Scrum de Scrums comunmente le sigue un "Meet After", o reunión posterior, para aquellos que deseen profundizar en problemas específicos. Para finalizar una de las responsabilidades del RTE es comunicar bloqueos, impedimentos mayores y retos a los interesados clave y, si es el caso, buscar y gestionar soluciones con éstos.

La clave para el éxito de Scrum de Scrums es que todos entiendan de la misma manera el propósito del evento. Uno de los grandes beneficios que he experimentado es como se forma y potencia la colaboración entre los Scrum Masters, y por ende entre los equipos. Fomenta que los Scrum Masters y equipos se preocupen unos por otros, y a medida que el tren madura los impedimentos llevados a Scrum de Scrums decrezcan porque se empiecen a resolver fuera del Scrum de Scrums. Se evidencia cuando en conversaciones la gente habla de problemas que han resuelto y que nunca llegaron al Scrum de Scrums.

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

¿Existe alguna simulación de Scrum on-line?

Autora facilitando la simulación

Dada la situación actual de COVID-19 muchos de nosotros, tanto coaches ágiles como trainers, tenemos necesidad de una simulación de Scrum on-line.

Algunos hemos preparado tableros FunRetro o tableros Miro para nuestros entrenamientos, y ahora, gracias a Timofey Yevgrashyn, tenemos opción a una simulación simple y realista para entrenar y fomentar la colaboración de nuestros equipos de desarrollo. El juego está diseñado para hasta 6 jugadores e incluye en su ejecución todos los eventos de Scrum a lo largo de 3 sprints de 3 días. A lo largo de la simulación ocurren problemas a los que el equipo se ha de enfrentar tomando decisiones colaborativas antes de que termine cada día de trabajo.

Tablero de inicio de la simulación Scrum Card Game

En la página web del juego podemos leer: "Scrum Card Game es un juego simple que permite a los jugadores experimentar el trabajo en sprints de Scrum, discutir muchas cuestiones y temas que suceden en la vida real mientras trabajan en un equipo Scrum. La discusión sobre la mesa de juego será muy cercana a la experiencia real del trabajo en un equipo Scrum. Este juego usualmente se juega durante un entrenamiento o taller. Los participantes ya deben conocer y entender el marco de trabajo Scrum o pueden aprenderlo mientras participan del juego. También puede servir como método para hacer que un equipo experimentado reflexione sobre sus rituales y reglas establecidas de Scrum".

Tablero que muestra el juego en curso

Uno de los puntos fuertes de esta simulación es que no tiene automatismos de flujo, llevando toda decisión sobre asignaciones y movimiento de historias de usuario a la autoorganización del equipo.

Iniciar simulación: Para acceder a la simulación podemos ir a la página de Scrum Card Game o directamente a la página del juego on-line. Pide un nombre y acto seguido genera un enlace para compartir con los demás jugadores para que puedan acceder a la simulación.

El tablero de inicio trae un pila de producto priorizada con historias de usuario preestimadas en puntos de dado.

Planificación de sprint: El Propietario del Producto explica cuáles son las historias más prioritarias a desarrollar. Toma en cuenta la capacidad del equipo, la cual puede ser estimada, por ejemplo, en función del máximo, mínimo o promedio de puntos de dado que puede sacar el equipo por sprint, con base en el número de miembros. El equipo decide cuantas historias va a abordar en el sprint, considerando todo lo anterior y las ha de arrastrar a la columna de "To Do".

Reunión diaria: Cada miembro se asigna a una o a varias historias. Dado que la simulación fomenta la colaboración, los miembros pueden hacer swarming y asignarse varios a una misma historia. Asignados los miembros a las correspondientes historias, éstos ya pueden lanzar sus dados y aplicar los puntos a las historias. El dado introduce en el juego la variabilidad que ocurre en la vida real. Con las jugadas también pueden ocurrir problemas o que un miembro adquiera una habilidad o una solución.

Los problemas bloquean una historia. Para solucionarlos el equipo decide aplicar una de las posibles soluciones que han ido adquiriendo a lo largo de las tiradas. Es importante tomar en cuenta que para que una historia pueda considerarse terminada (Done) no debe tener puntos por hacer y no debe tener ningún bloqueo.

Resolución de problemas en la daily

Revisión de sprint y retrospectiva: Después del tercer día el equipo realiza la revisión del sprint, con base en el tablero, comparando historias planificadas versus historias terminadas, y luego realiza una retrospectiva para reflexionar sobre la forma en la que han trabajado, y acordar acciones concretas que puedan mejorar su forma de trabajar en el siguiente sprint.

Debrief: Después de tres sprints la ejecución de la simulación finaliza y es momento de analizar los aprendizajes: planeado versus real, variaciones en la velocidad, riesgos que sucedieron (técnicos, de personas, eventos no planeados, ...)...

La simulación en su versión original se diseñó para jugarla de manera presencial, y la web de Scrum Card Game ofrece varias alternativas para comprarlo.

Tablero descargable y fichas que se pueden comprar para jugar en presencial

Timofey Yevgrashyn, el autor, da opción a descargar el manual de la versión de IT (software) de forma gratuita. Esta incluye el set de fichas para poder imprimirlas para poder jugar la simulación en presencial. Podéis encontrar el manual descargable en este enlace.

Finalmente quiero invitar a quién se decida a jugar esta simulación que eche un vistazo al video "How to play Online Scrum Card Game" en YouTube y a que comparta su experiencia en los comentarios de este post.

Partida de Scrum Card Game en un curso on-line de Scrum Manager - Gracias a todos!!!