Jugando Cynefin Lego Game en el Road to BAOS 2017

davSiguiendo con los workshops organizados en la Comunidad Madriagil en el Road to BAOS 2017 por João Barreiro y Unai Roldán, el sábado pasado compartimos una maravillosa experiencia que consistió en un taller donde jugamos al Cynefin Lego Game de Andrea Tomasini,  que permite experimentar cuatro de los cinco dominios del marco de trabajo Cynefin de David Snowden.

Cynefin* se utiliza en el marco de las metodologías ágiles para darles una base científica. Surge de investigaciones en los ámbitos de la teoría de sistemas,Modelo Cynefin la teoría de la complejidad, la teoría de la red y teorías de aprendizaje y es muy útil para entender y explicar porqué distintos enfoques de trabajo y de hacer las cosas funcionan bien en un entorno y en otro no. Cynefin compara cinco dominios de distinta complejidad: Obvio, Complicado, Complejo, Caótico y Desorden y define sus características principales, lo que nos da una guía para identificarlos en nuestros entornos de trabajo y de esta manera tomar decisiones e implementar acciones de una manera más informada con el objeto de mejorar la forma de trabajar y tratar de reducir su nivel de complejidad en la medida de lo posible.

Primera ronda del juego

El objetivo de la primera ronda fue trabajar con el cuadrante de lo Obvio, donde las relaciones causa efecto son obvias y la manera de hacer las cosas es conocida por todos, muchas veces rutinaria y no requiere pensar mucho antes de comenzar a trabajar, por lo que existen mejores practicas o se pueden identificar fácilmente. Es el entorno que más se corresponde con el área de operaciones.

Nuestra tarea fue coger las piezas, separarlas por colores y hacer un grupo especial para las piezas raras (ruedas, engranajes, etc.). A continuación pueden observar el resultado:

resultado de la primera ronda

foto iratxe

grupo cpn piezas separadas

Una vez hecha la tarea reflexionamos sobre las buenas prácticas que habíamos aplicado, que fueron: ponernos de acuerdo para ver como íbamos a trabajar, dividiendo el trabajo de cada miembro del equipo por tonos de piezas y colaborar con los otros miembros pasando piezas del tono que estaba trabajando.

Segunda ronda del juego

El objetivo de la segunda ronda del juego fue trabajar con el cuadrante de lo Complicado, donde las relaciones causa-efecto no son obvias, pueden haber muchas buenas practicas para resolver un mismo problema, se necesitan expertos que orienten hacia cuál es la mejor y se necesita pensar antes de comenzar a trabajar.

La tarea fue, después de juntar las piezas que habíamos separado por colores, construir una torre lo más alta posible, siguiendo un patrón de colores y donde las piezas de arriba no fueran más grandes que las piezas de abajo. A continuación pueden observar el resultado de cada equipo:

Resultado de la segunda rondaTorre del grupo de IratxeResultado de la segunda ronda 2

Una vez hecha la tarea reflexionamos sobre las buenas prácticas que habíamos aplicado. Lo primero es que tuvimos un tiempo para pensar y para planificar cómo íbamos a hacer el trabajo y nos coordinamos e interactuamos mucho más que en la primera ronda.

Tercera ronda del juego

El objetivo de la tercera ronda del juego fue trabajar con el cuadrante de lo Complejo, donde las relaciones causa-efecto existen pero para entenderlas hay que mirar al pasado, no hay buenas prácticas identificadas y hay que probar soluciones para ver si funcionan o no. Para trabajar en este cuadrante hace falta mucha creatividad, innovación e intercambio de ideas.

La tarea fue, después de desmontar la torre de la ronda anterior, construir un animal siguiendo un patrón de colores, cada miembro del equipo sólo podía tocar un color y no podíamos hablar entre nosotros. A continuación pueden observar el resultado de varios equipos:

Resultado de la ronda 3 1                      Serpiente construida en la tercera ronda para trabajar lo Complejo

Resultado de la segunda ronda 3                       Elefante construido en la tercera ronda para trabajar lo Complejo

dav
Otra serpiente construida en la tercera ronda para trabajar lo Complejo

Aquí nos dimos cuenta que era necesario comunicarnos de alguna forma, y como no podíamos hablar en dos equipos nos comunicamos a través de notas escritas y otro grupo se comunicó a través de señas. Al encontrar la manera de comunicarnos pudimos ponernos de acuerdo en el animal a construir, qué color y en qué partes del animal iba a trabajar cada uno.

Cuarta ronda del juego

El objetivo de la cuarta ronda del juego fue trabajar con el cuadrante de lo Caótico, donde no tienes tiempo de pensar, haces algo y lo pruebas para ver si funciona y se reduce el nivel de caos existente para tratar de llevarlo a una situación de complejidad.

La tarea fue, después de desmontar el animal de la ronda anterior, construir un vehículo, sin hablar entre nosotros, siguiendo un patrón de colores, donde cada color podía ser tocado por una sola persona y cuando Unai tocara a alguien del equipo se lo llevaba a otro equipo. A continuación pueden observar el resultado de varios equipos:

Resultado de la ronda 4 2

Resultado de la ronda 4 1jpeg

Vehículo del grupo de Iratxe

Aquí el caos se producía cuando alguien del equipo se iba a otro equipo y llegaba alguien nuevo. Había que tratar de solucionar esa situación de alguna manera para que el nuevo miembro se incorporara al equipo y entendiera que es lo que se estaba haciendo y la forma en la que podía participar. Lo hacíamos por señas y cuando no veíamos la forma de participar en un nuevo equipo, lo mejor que podíamos hacer era no hacer nada para no entorpecer el trabajo de los demás.

En la parte final del taller compartimos opiniones y entre otras llegamos a concluir lo siguiente:

  • A nivel metodológico tenemos que detectar en que cuadrante estamos y con base en esto pensar como actuar
  • La ayuda para tratar de reducir la complejidad está en las buenas prácticas
  • Con el tiempo, nuestros productos cambian de un cuadrante a otro
  • Scrum es un marco de trabajo para construir productos complejos de una manera sencilla
  • Cynefin se ha visto que funciona mejor cuando el equipo habla directamente con el cliente e intercambian ideas y opciones de como reducir la complejidad
  • Hay que buscar que, culturalmente, los equipos se sientan cómodos en entornos complejos
  • Si cortamos los hilos de feedback y no conocemos los resultados de las acciones que acometemos, hay problemas.
  • En sistemas complejos a veces hay intereses ocultos que no sabemos que existen y que pueden ser la causa de muchas situaciones inexplicables.

Muchas Gracias a Unai y a João por organizar y conducir el taller y a todos los que participamos. Fue una mañana llena de aprendizajes y diversión.

Saludos Cordiales y espero que el post os sea de utilidad así como espero vuestros comentarios

Gertrudis

*: Otros posts interesantes sobre Cynefin
http://www.javiergarzas.com/2016/07/entendiendo-modelo-cynefin.html
http://www.martinalaimo.com/es/blog/cynefin

Anuncios

¿Cómo hacer una estimación rápida de una gran pila de producto?

EstimacionAtPresentaciónRecientemente Juanma Gómez, João Barreiro (en la foto de la izquierda explicando el proceso) y Unai Roldán organizaron en Madriagil ) un workshop sobre estimación en escalado #estimationatscale. El objetivo de este workshop fue experimentar practicando una manera rápida de hacer la estimación inicial de una pila de producto de un producto grande de forma escalada.

Cuando pretendemos abordar un nuevo proyecto los requisitos iniciales nos llevan a grandes funcionalidades o módulos que en la pila de producto inicial se materializan como épicas. Ese será el punto de partida. La estrategia de estimationatscale es desglosar una épica en features, una de ellas en historias de usuario, estimar las historias en relativo, agregar estimaciones para obtener la estimación de la feature, estimar features en relativo respecto a esa feature de referencia, agregar estimaciones para obtener la estimación de la épica y finalmente estimar épicas en relativo.

La estimación a escala debe de partir de una pila de épicas creada por un user story mapping hecho por el equipo de negocio. En el taller de estimación en escala debe de estar presente el equipo de negocio y el equipo de desarrollo: de forma colaborativa desglosarán las épicas y features, y solo el equipo de desarrollo, quienes vayan a construir esas funcionalidades, estimarán el esfuerzo de los elementos en base a complejidad y tamaño.

Pasos a seguir para la estimación en escala:

dig

1. Elegir la épica más importante

Partimos de una fila de épicas colocadas en un tablero o pared, en nuestro workshop estas están representadas por post-its de color azul. El Propietario del Producto elije la épica más importante, la que más valor de negocio tenga.

2. Desglosar épica

De forma colaborativa negocio y equipo de desarrollo desglosan la épica en features, grandes funcionalidades representadas por post-its de color verde en nuestro caso.

EstimacionAtScaleEpicaDesglosada

Épica más importante( post-it azul) desglosada en Features (post-its verdes)

3. Elegir la feature más importante

De nuevo el Propietario del Producto elije en este caso la feature más importante, la que más valor de negocio tenga.

4. Desglosar feature

De forma colaborativa negocio y equipo de desarrollo desglosan la feature en historias de usuario, elementos de la pila lo suficientemente pequeñas para poder ser estimadas con las cartas de planning poker usuales, las que se basan en la serie de Fibonacci. Las historias de usuario están representadas por post-its de color amarillo en el workshop.

EstimacionAtScaleFeatureDesglosada

Feature ( post-it verde) desglosada en historias de usuario (post-its amarillos)

5. Calibrar escala

Para calibrar la escala el equipo elige una de las historias de usuario que represente la velocidad aproximada del equipo, el tamaño de esfuerzo realizable en un sprint, y le asigna el 21.

EstimacionAtScaleCalibración.jpg

Historia de usuario que representa la velocidad estimada del equipo
calibrada con el número 21 de la serie de Fibonacci

6. Estimar historias de usuario

En base a la historia de de referencia 21 el equipo estima en relativo el resto de historias. Para el workshop UST Global nos ha proporcionado todos los participantes de barajas con la ¡serie de Fibonacci hasta el 987! Esta baraja nos posibilita la estimación relativa a los tres niveles de escalado de la pila de producto.

EstimacionAtScaleBarajaCartas

Cartas de planning poker para estimar en escalado proporcionadas por UST Global

En otro tablero o pared se crean post-its con la serie de Fibonacci, los mismos valores que las cartas de la baraja. En nuestro workshop estos se representaron sobre post-its rosas o naranjas (dependiendo del grupo). Una vez estimada una historia esta se coloca en el tablero o pared debajo del valor resultante.

dav

Equipo estimando historia de usuario usando la técnica del Planning Poker con los números de la serie de Fibonacci 

7. Estimar features

Una vez estimadas todas las historias, se suman todas las estimaciones y la feature más importante se le asigna ese valor conviertiéndola en la feature de referencia para la estimación de features. A medida que se estiman features estas se colocan en el tablero o pared bajo el valor correspondiente.

EstimacionAtScaleFeatureEstimada

Features estimadas (post-its de color verde) con valores de la serie de Fibonacci a partir de la estimación de la Feature de referencia

8. Estimar épicas

Del mismo modo que la estimación de features, se agregan las estimaciones de las features para el valor de la épica más importante y se sigue el mismo proceso de estimación.

EstimacionAtScaleEpicasEstimadas

Épicas estimadas (post-its de color azul) con valores de la serie de Fibonacci a partir de la estimación de la épica de referencia

sdrUna vez obtenida la estimación de las épicas, y en base a la métrica objetiva de velocidad del equipo o diferentes velocidades de los diferentes equipos, podemos proyectar hitos de fechas entrega, proyecciones que, aunque no precisas, nos llevan a un plan factible.

Recordemos que las estimaciones son aproximaciones que nos dan un valor útil para tomar decisiones acertadas, no son valoraciones estrictas y precisas para elaborar un plan milimetrado.

Agradecimientos a todos los participantes del workshop, ha sido un placer practicar #estimationatscale con todos vosotros.

Deseo que el post os sea de utilidad y espero vuestros comentarios

Saludos Cordiales,

Post escrito conjuntamente con Alexander Menzinsky