¿Qué tipo de retrospectiva hacer al finalizar un curso o un evento?

Estuve haciendo co-trainig con Marcos Garrido y me ha gustado mucho su forma de hacer la retrospectiva a final de curso. La idea trata no sólo de obtener feedback del curso, sino de que los propios alumnos se lleven lo que sea esencial para ellos. Pronto me di cuenta de que esta técnica es aplicable a cualquier evento en el que haya transmisión de conocimiento. El tablero propuesto tiene 4 áreas:

Tablero con 4 áreas

• Sentimientos
• Aprendido
• Desafíos
• Plan de acción

Cada alumno escribe 1 post-it por área y los coloca en el área correspondiente.

Nuestro tablero de retrospectiva

Sentimientos: La primera área es para recoger feedback de los alumnos y ocurre a través de lo emocional, desde la experiencia que estos han vivido. Aparecen sentimientos como satisfacción, ganas de aplicar lo aprendido, smileys sonrientes así como smileys tristes...

Las otras tres áreas son para el alumno, están pensadas en forma de flujo para que guíen al alumno hacía la implantación en su día a día profesional de algunas de las técnicas aprendidas.

Aprendido: En primer lugar el alumno hace inventario de lo aprendido y expone lo que más le interesa o lo que más importante le parece.

Desafíos: En segundo lugar proyecta ese conocimiento nuevo a su trabajo e identifica dónde hay retos y desafíos para la implantación de lo aprendido y que considera interesante.

Plan de acción: Una vez asumidos los retos y desafíos el alumno identifica qué técnica aprendida querría aplicar y dónde, de forma que a modo de PNL se lleva un plan de acción consigo.

Mis agradecimientos a Marcos por su técnica y por todo lo aprendido a su lado :-)

¿Qué hacer cuando "explota" una retrospectiva?

Hace poco participé en un meetup de Madriagil en que conversamos sobre temas de Agilidad en un fishbowl, en concreto lanzábamos preguntas de interés y discutíamos alrededor de estas. Una de las preguntas me llamó mucho la atención, así que con este post pretendo recoger el conocimiento que se generó, y enriquecerlo con mi experiencia.

Una retrospectiva desde fuera

Una retrospectiva "explota" cuando los miembros del equipo empiezan a culparse los unos a otros por todos los problemas acaecidos en el proyecto/producto. Esta explosión evidencia una larga serie de retrospectivas y prácticas ágiles mal llevadas, ocurre cuando se produce esa gota que colma el vaso.

Si llega a producirse esta situación lo que hemos de hacer como Scrum Masters es parar en seco la retrospectiva, esperar unos días para dejar reposar y enfriar las diferencias y los enfrentamientos entre los miembros del equipo, y después cambiar de contexto y espacio para dar los primeros pasos para la recuperación en el ritmo de restrospectivas.

Si en la compañía existiese la figura del coach ágil hablad con él, contadle y dejaos ayudar, y si no lo hubiese, apoyaros en otros Scrum Masters que pueda haber.

El mejor primer entorno para resolver es el lúdico, el que está totalmente desligado del trabajo y genere team-building, unas cervezas por ejemplo, la cerveza tomada con moderación tiene la propiedad de relajar las tensiones :-)

Para enfrentarse a la primera retrospectiva posterior haceros las siguientes preguntas:

• ¿Estamos todos preparados para una retrospectiva?
• ¿El equipo quiere mejorar y aprender cosas nuevas?
• ¿Afloran los sentimientos respecto al equipo/proyecto/producto en las retrospectivas?
• ¿Hay uno o dos miembros que dominen la conversación?
• ¿En las retrospectivas anteriores se han mantenido el foco?
• ¿El foco ha estado mayoritariamente en impedimentos exteriores cuya resolución no depende del equipo?
• ¿Se ha implementado una acción de mejora con cada retrospectiva?

Intentad manejar y gestionar las respuestas a esas preguntas, replantearos la manera en las que facilitáis y balanceáis las retrospectivas, incluid un área de agradecimientos si no la tenéis ya, resultará sorprendente lo que lleva a motivar esa idea tan simple.

Para medir la salud del equipo recomiendo la técnica del histograma de satisfacción.

Y recordad: si no haces retrospectivas no haces Scrum

Quiero dar mi agradecimiento a los participantes del meetup "Agile Manifesto: Back to Basics" en el que tratamos este tema, especialmente a Tino y a Antonio que fueron los que lo organizaron.

¿Cómo configurar las mesas de los equipos de Scrum?

Scrum tiene reglas muy simples pero difíciles de implantar, después de un camino nada fácil hemos conseguido por fin un par de equipos funcionando con Scrum, y ahora estamos preparándonos para el futuro trabajando en como configurar equipos Scrum en una sala con más de 10 equipos y 100 personas.

Tal como nos enseña Alistair Cockburn seguimos una de sus reglas:

"El equipo debe estar sentado con una separación no superior
a la longitud de un autobús escolar"

Estamos diseñando espacios exclusivos por equipo, de manera que el entorno facilite las prácticas de Scrum:

• Que estén juntos y puedan comunicarse cara a cara, no hay mejor comunicación, especialmente cuando se trata de cuestiones complejas.
• Que sea fácil colaborar y sentarse al lado de cualquier otro miembro.
• Que tengan su espacio y puedan realizar sus reuniones diarias de pie ante el tablero de Scrum.
• Que sea posible la comunicación osmótica; ocurre cuando los miembros prestan atención de forma automática, como por ósmosis, a conversaciones entre otros miembros que para ellos también son relevantes.

También es importante que los equipos tengan un poco de libertad para ajustar su entorno:

• Sillas con ruedas para que puedan moverse libremente en su espacio.
• Un tablero grande que sea cómodo y permita incluir otras áreas que les puedan ser útiles.

Para configurar las mesas hemos hecho una encuesta a los equipos de la sala y hemos diseñado dos patrones:

Dos patrones, equipos azules y rojos

Los equipos azules, los de la izquierda de la figura, son equipos que prefieren verse las caras en todo momento y que se sientan alrededor de la mesa:

• Todos los miembros tienen visión directa hacia los demás miembros.
• Tienen un espacio para las reuniones diarias y el tablero en un extremo de la mesa.
• Se pueden desplazar fácilmente en su lado de la mesa.

Los equipos rojos, los de la derecha de la figura, son equipos para los que la movilidad es importante y que se sientan alrededor del pasillo entre mesas:

• Todo el pasillo es su espacio.
• Celebran las reuniones diarias al final del pasillo ante su tablero.
• Cualquiera puede desplazarse al lado de cualquier otro miembro muy fácilmente.

Disposición de uno de los equipos rojos :-)

He observado que los equipos más maduros en Agilidad prefieren ser rojos, seguramente porque prefieren la comunicación cara a cara y la colaboración forma parte de su día a día, cuando hay algo que tratar se sientan unos al lado de los otros. Los equipos que prefieren ser azules suelen ser equipos que provienen de proyectos no ágiles. Cuando les pregunto si no es mejor tener facilidad de sentarse uno al lado de otros, me contestan que ellos prefieren quedarse en su sitio, situarse en el mismo código en su pantalla, y a partir de ahí hablar y discutir.

Finalmente hemos configurado la sala con equipos rojos a un lado y azules al otro. En el lado de los equipos rojos hemos utilizado los dos extremos de filas libres para dos equipos pequeños de 3 y 4 miembros.

¿Hay algún juego para crear e integrar equipos Kanban?

Tablero getKanban en el décimo día

Termino mis cursos de Lean-Kanban con una simulación muy completa que dura 3 horas y que consiste en experimentar los principios de Kanban, límites WIP, el sistema de arrastre y las diferentes herramientas y prácticas que propone Kanban. Utilizo la versión 2 del juego "The getKanban Board Game" que se puede descargar gratuitamente en formato pdf.

En el último curso que di, un alumno, que es jefe de proyecto, exclamó: "¡Este juego es ideal para crear equipos, muestra las fortalezas y debilidades de cada uno y nos integra como personas en un equipo!", fue tan revelador que apunté la frase y decidí en ese mismo momento que escribiría un post. Una vez terminado el juego siempre les pregunto a los asistentes por lo que han experimentado y sentido, y dicen frases como:

• Al principio nos teníamos que coordinar mucho, luego ya sabíamos que cada uno estaría haciendo lo suyo.
• Todos teníamos la misma visión completa del trabajo a realizar y del objetivo a alcanzar.
• La estrategia para decidir que tareas acometer salía de todos nosotros.
• Aunque explicitábamos las políticas escribiéndolas, todos las teníamos clarísimas.
• Sentimos como colaboramos y que formamos un equipo.

Este es un ejercicio del curso de Kanban de

El juego es un juego con una duración relativamente larga, 3 horas son suficientes para permitir una autentica interacción y hacer team-buidling entre los participantes. Es aplicable a todo tipo de equipos, desde equipos en que los miembros trabajan juntos a los que están deslocalizados. Se puede enfocar como una actividad lúdica convocando un sábado o fin de semana a todos los miembros, realizando el juego y luego redondeando el día con una comida o cena. :-)

Un hecho interesante que observo una y otra vez es que, aunque ofrezca $10.000 de premio al equipo que acabe antes, cada uno va a lo suyo y a su ritmo, no les motiva en exceso ese premio. Eso quiere decir que efectivamente acaban entrando en flujo y la motivación es el propio juego, el formar parte de y participar del juego como equipo.

Sobre el juego

Disposición de los jugadores, About the Game

El juego se juega en equipos de entre cuatro y seis personas, y a un juego por equipo. Cada equipo tiene un tablero que representa un tablero Kanban, y una colección de tareas u historias de usuario que representan los items del trabajo a hacer. Los equipos compiten para maximizar los beneficios mediante la optimización del flujo de trabajo.

Durante el juego los equipos elaboran gráficos a partir de los datos del juego, incluyendo un diagrama de flujo acumulado y un diagrama de control estadístico. Se producen eventos simulados durante todo el juego para desafiar a los equipos y obligarles a rediseñar sus estrategias, establecer prioridades y a tomar decisiones sobre la asignación de recursos.

Los gráficos del juego: diagrama de control estadístico, diagrama de flujo acumulado y análisis financiero

---

Para aquellos que quieran probar esta experiencia en remoto podéis utilizar Kanban Board Game, un simulador basado en Get Kanban Game versión 2. Cuenta con el mismo tablero, las mismas fichas, los mismos dados y los mismos gráficos que el juego original.

Tablero de la simulación en el día 9

Resultados en forma gráfica: diagrama de flujo acumulado, análisis financiero y diagrama de control estadístico

Quiero dar mis agradecimientos a The Fullmetal Agilist que con su artículo ¡Simulaciones Kanban a distancia! nos comparte su conocimiento sobre simulaciones Kanban :-)

¿Cómo escribir los criterios de aceptación?

Después de 50 años de historia de ingeniería de software hemos llegado a la conclusión de que los criterios de aceptación, que son el detalle de las historias de usuarios desde el punto de vista de testing y se traducen en pruebas, son un excelente lenguaje para especificar requisitos funcionales, y es por ello que toman tanta importancia en las historias de usuario.

Buenas prácticas con criterios de aceptación
Cortesía de Miguel Angel Sobrino

Para medir la calidad de un criterio de aceptación se utiliza el método SMART en el que se han de cumplir en lo máximo posible los siguientes criterios:

• S - Specific (Específicos)
• M - Measurable (Medibles)
• A - Achievable (Alcanzables)
• R - Relevant (Relevantes)
• T - Time-boxed (Limitados en el tiempo)

Se suelen escribir en forma de checklist o descripción de un flujo en cuanto se obtengan historias de usuario susceptibles de entrar en un sprint, y se acaban de refinar en la planificación de sprint. Los criterios de aceptación ayudan al equipo de desarrollo a entender el funcionamiento del producto, de manera que estimarán mejor el tamaño de la historia subyacente y, cuando el equipo se encuentre en fase de desarrollo servirá de guía cuando el desarrollador tenga que tomar una decisión, tomará la más acertada.

Finalmente, y a modo del viejo truco del palillo en repostería, como lo describe Tamara Vázquez en su post sobre criterios de aceptación, si se mete un palillo en la porción de tarta, que representa el incremento del sprint, y sale limpio, es que la porción de tarta está bien hecha, de la misma manera que el Propietario del Producto comprueba en la revisión de sprint, a través de estos criterios de aceptación y la definición de hecho, si la historia de usuario se puede dar como hecha y finalizada.

Diferentes formatos para escribir criterios de aceptación:

Comprobar [Criterios]

Demostrar [Comportamiento esperado]

Verificar que cuando [Rol] hace [Acción] consigue [Resultado / Comportamiento esperado]

Dado que [Contexto] y adicionalmente [Contexto] cuando [Evento]

entonces [Resultado / Comportamiento esperado]

Sintaxis gherkin para describir el comportamiento del software

Actualmente estoy acompañando a una serie de proyectos en los que estamos escribiendo los criterios de aceptación con el lenguaje natural, tal como el Propietario del Producto se expresa. Mirando hacia el futuro estamos planteándonos si escribirlos con la técnica del comportamiento por escenarios. Así, cuando implantemos BDD (Behavior Driven Development), los usuarios de negocio y los Propietarios del Producto estarán acostumbrados a escribirlos de esa forma, en concreto pensamos en implantar gherkin, el lenguaje específico creado especialmente para las descripciones de comportamiento de software. La sintaxis de gherkin es la siguiente:

(Scenario) Escenario [Número de escenario] [Titulo del escenario]:

(Given) Dado que [Contexto] y adicionalmente [Contexto],

(When) cuando [Evento],

(Then) entonces [Resultado / Comportamiento esperado]

Derivado de esta sintaxis los elementos de los criterios de aceptación son:

• Número de escenario: Número (ejemplo 1, 2, 3 ó 4), que identifica al escenario asociado a la historia.
• Título del escenario: Describe el contexto del escenario que define un comportamiento.
• Contexto: Proporciona mayor descripción sobre las condiciones que desencadenan el escenario.
• Evento: Representa la acción que el usuario ejecuta, en el contexto definido para el escenario.
• Resultado / Comportamiento esperado: Dado el contexto y la acción ejecutada por el usuario, la consecuencia es el comportamiento del sistema en esa situación.

Ejemplo:

Partimos de la siguiente historia de usuario:

Como cliente

Quiero retirar dinero del cajero automático

Para poder evitar ir al banco a hacer una cola

y escribimos los criterios de aceptación en gherkin:

Escenario 1: Cuenta tiene crédito

Dado que la cuenta tiene crédito

y que la tarjeta es válida

y que el cajero tiene dinero disponible

Cuando el cliente pide dinero

Entonces la cuenta es debitada

y el dinero es entregado al cliente

y el cliente recupera su tarjeta

Escenario 2: La cuenta excede el límite negativo acordado con el banco

Dado que la cuenta excede el límite negativo acordado con el banco

y que la tarjeta es válida

Cuando el cliente pide dinero

Entonces el cajero muestra un mensaje negando el pedido

y el dinero no es entregado al cliente

y el cliente recupera su tarjeta

Plantilla para criterios de aceptación,
cortesía de La Oficina de Proyectos de Informática

PMOInformática.com nos propone una excelente plantilla para recoger y documentar las historias de usuario y sus criterios de aceptación, plantilla que está libre de derechos de autor y puede ser usada libremente (descargar plantilla) :-)

En su página muestran el siguiente ejemplo de un criterio de aceptación:

Escenario 1: Dado que existe una categoría sin productos asociados, cuando el cliente despliegue el listado de categorías para realizar su búsqueda, entonces el sistema mostrará el siguiente texto al lado de la categoría "Actualmente no poseemos productos para esta categoría".

¿Existe alguna dinámica lúdica para hacer team-building?

Cartel anunciando la dinámica en el bar

Pues sí las hay, voy a presentar la dinámica lúdica que Allan Rennebo nos enseñó con su Beer Taste Kanban durante el Scrum Coaching Retreat 2015 en Alemania. Fue una de las propuestas Open Space programadas para las actividades vespertinas.

Esta dinámica está indicada para después de la jornada laboral, es muy recomendable no practicarla si hay que volver a la oficina. :-P

Jugar la dinámica en un bar de confianza no debe de preocuparnos por el hecho de desembarcar con un flip-board en el mismo y marcar las casillas en una mesa con cinta de carrocero. Los camareros y barmans han visto cosas mucho más increíbles, jajajaja, así me lo dijo el del bar donde jugamos.

Así es como funciona:

• No hay límite de participantes, el límite serán el tamaño de la mesa y el tablero.
• Preparamos el tablero con los siguientes estados: Ready (Listo), Tasting (Catando) y Done (Hecho).
• Colocamos tantos post-its en la columna Ready como variedades de cerveza se van a catar, apuntamos la variedad en el post-it.
• Preparamos la mesa con seis casillas que etiquetamos del 1 al 6 con post-its. Los números representan la valoración de la cerveza, siendo el 6 la valoración más alta y el 1 la más baja.

Mesa preparada para el Beer Taste Kanban

• Preparamos tantas cañas, preferiblemente pequeñas, como participantes y variedades de cerveza se van a estudiar. Por cada participante habrá una caña de cada variedad de cervezas.



Participante ante la pizarra

• Empezamos con un WIP = 4 en la columna Tasting, eso quiere decir que solo puede haber 4 participantes bebiendo su cerveza a la vez.
• Por cada tipo de cerveza hacemos una ronda, al cambiar de ronda variaremos el WIP.
• Uno de los participantes se le da la responsabilidad de cronometrar.
• Decidimos que variedad vamos a probar, apuntamos el WIP y movemos el post-it a Tasting.
• A la voz de "YA"  del cronometrador tantos participantes como permita el WIP beben una caña de la variedad lo más rápido que pueden, y colocan el vaso vacío en la casilla que corresponde a su valoración. Con cada vaso colocado en la mesa se libera un elemento del WIP y otro participante puede beber su cerveza.
• Cuando todos hayan catado y colocado los vasos vacíos en la mesa, sumamos todas las valoraciones y las apuntamos en el post-it.
• El cronometrador para el reloj y apunta el tiempo en el post-it y finalmente lo mueve a Done.
• Hacemos una breve retrospectiva y decidimos el WIP para la siguiente ronda.
• Pasamos a la siguiente ronda.

El objetivo de la dinámica es averiguar cuál es el WIP que minimiza el tiempo de servicio para valorar una variedad dada de cerveza.

Después de 5-6 variedades de cerveza las medidas no son muy poco fiables, jajaja, pero el objetivo principal de la dinámica se habrá cumplido, habremos hecho team-building.

Una de las conclusiones que hemos sacado del juego es que el tiempo se minimiza con WIP = 1. Os invito a jugar y a sacar vuestras propias conclusiones... una cosa si os aseguro, serán conclusiones muy alegres y coloridas.

Many thanks to Allan Rennebo who teached me this game and played it with us :-)

¿Existe algún tablero para hacer seguimiento de las interacciones de un coach ágil?

Una de las misiones fundamentales de un coach ágil es la de abrir canales de comunicación entre todos los interesados de la compañía, incluido él mismo. Uno de los pilares de la Agilidad es la comunicación, tal como dice el primer valor del Manifiesto Ágil:

Individuos e interacciones sobre procesos y herramientas

Hasta existen técnicas de retrospectiva, como el Triangulo Retrospectivo, que se basa en analizar las interacciones entre los distintos roles e interesados.

My personal interaction matrix

Uno de los grupos de trabajo del Scrum Coaching Retreat 2015 de Alemania trabajó en una caja de herramientas para el coach y entre ellas estaba este tablero con una matriz de interacciones personales que quiero mostrar en este post.

Su propuesta consta de tres columnas:

• En la primera se colocan los diferentes grupos con los que interactuamos como coach (gerencia, mandos intermedios, líderes de equipo o Propietarios del Producto, equipos de desarrollo e individuos)
• En la segunda columna, encabezada por un 1, anotamos con un palito cada interacción con el grupo que haya habido durante el sprint. A final de sprint debe de haber una distribución equilibrada de interacciones en forma de curva de Gauss: alguna interacción con gerencia e individuos y bastantes con el resto de los grupos. La carencia de interacciones con alguno de los grupos indicará en dónde trabajar para el próximo sprint.
• En la tercera columna, encabezada con "week 2", se pone un post-it por cada interacción importante ocurrida durante el sprint. En los post-its figuran el coach y su interlocutor, se anotan los nombres y algunas palabras clave expresadas por cada uno y en la cara se dibujan caritas alegres o tristes. Interacciones exitosas tienen una carita alegre, e interacciones problemáticas una carita triste. De esta forma sabemos cuáles son las interacciones sobre las que hay que trabajar para el sprint que viene.

Voy a poner en marcha mi propio tablero y contaré en este mismo post cuál es mi experiencia :-)

Many thanks to Scrum Coaching Retreat 2015 group that designed this matrix.