¿Cómo hacer una retrospectiva distribuida con equipos deslocalizados? Taller de Retrospectivas Distribuidas en el #Bye2BAOS

Una retrospectiva distribuida es una retrospectiva en la que los miembros de los equipos están en más de una localización, por ejemplo, desde diferentes ciudades en España a diferentes países de todo el mundo. Hoy en día ocurre en muchas empresas: trabajan en un mismo producto con equipos en países tan diversos como Estados Unidos, Inglaterra, India, China… y en este post pretendemos dar algunas herramientas de cómo poder realizar este tipo de retrospectiva.

Como caso práctico para experimentar una retrospectiva distribuida Gema Ruíz-Díaz Mariblanca y João Barreiro organizaron el #Bye2BAOS, un taller práctico de retrospectiva distribuida como cierre del conjunto de eventos organizados en el #ROAD2BAOS con un doble propósito: aprender sobre retrospectivas distribuidas a través de la experimentación directa y hacer la retrospectiva del BAOS 2017

El lugar

Para simular equipos deslocalizados fue necesario un espacio grande donde los equipos no pudieran ni verse ni escucharse. El sitio elegido fue el Matadero de Madrid, específicamente Café Teatro, un lugar superculturoso con un entorno propicio para el arte, la inspiración, la innovación y la creatividad.

Imagenes del matadero

Los equipos

Después de una breve introducción al taller y a las retrospectivas distribuidas, nos dividimos en tres equipos, cada uno de ellos con un facilitador: el Equipo Glaciar con Gema de facilitadora, el equipo CoraBAOS con João de facilitador y el equipo CoffeePanda con Elvira de facilitadora. Cada equipo se ubicó en espacios distintos en la cafetería del Matadero. Originalmente la idea era que estuviéramos distribuidos en distintas salas, pero por problemas de conectividad no se pudo.

Los equipos

Las herramientas

Para hacer una retrospectiva distribuida se necesitan dos clases de herramientas, una de videoconferencia que permita vernos las caras y escuchar nuestras palabras entre todos los equipos y un tablero virtual compartido donde reflejar los post-its de la retrospectiva.

Para el taller usamos las siguientes herramientas libres:

Appea inLas herramientas

appear.in es una herramienta de colaboración por vídeo que permite tener conversaciones de vídeo sin esfuerzo con hasta 8 personas/equipos simultáneamente.

La versión premium admite hasta 12 personas/equipos. Se puede crear una sala sin necesidad de registrarse y también permite registrarse para comprar y personalizar enlaces propios de sala de vídeo.

appear.in funciona en casi cualquier dispositivo e incluso le permite compartir su pantalla para mostrar presentaciones, fotos u hojas de cálculo.

Funretro

Fun Retro un tablero virtual para recopilar datos, hablar sobre las cosas positivas, reconocer a las personas y buscar mejoras. Permite hacer visible la retrospectiva para todos los participantes, seleccionar una actividad y crear y personaliza el tablero. ¡A por ello!

El taller

El objetivo principal de la retrospectiva distribuida fue obtener feedback sobre el BAOS 2017 y generar ideas para hacer un gran BAOS 2018, en particular:

  • Definir cuál es la identidad percibida del BAOS
  • Saber si el BAOS 2017 fue un éxito, un fracaso o un evento más, y por qué
  • Conocer cuáles fueron las cosas buenas y las cosas a mejorar del BAOS 2017 y
  • Generar ideas para construir una gran BAOS 2018.

Una vez que nos distribuimos en equipos, comenzamos el taller con una actividad para romper el hielo dentro de cada equipo y luego entre los equipos. Esta actividad es fundamental en cualquier retrospectiva distribuida, ya que fomenta la confianza y la participación de todos. En este caso, y para romper el hielo, cada persona dijo su nombre y cuál era el libro que estaba leyendo actualmente.

En esta actividad pudimos vivir una de las cosas que puede pasar en las retrospectivas distribuidas: los fallos tecnológicos y de comunicación, aprendimos que siempre hay que tener un plan B y hasta un plan C para aumentar al máximo las probabilidades de poder seguir adelante con la retrospectiva hasta el final. En el taller tuvimos problemas técnicos, la herramienta de videoconferencia no funcionó en todos los equipos, así que optamos por el plan B de hacer partícipe al equipo afectado por teléfono :). La llamada telefónica tiene sus limitaciones, no ver con quien conversas y el ruido ambiental exterior dificultó oír y entender lo que decían los demás equipos.

Luego cada equipo eligió un nombre. Primero generamos palabras por parejas y luego las combinamos creando una nueva a partir de la asociación de las palabras raíz. De aquí surgieron los equipos Glaciar, CoreBAOS y CoffeePanda. Luego estos nombres de equipo se usaron para poder identificar los post-its de cada equipo en el tablero de la retrospectiva.

Finalmente pasamos a hacer la retrospectiva en individual por equipo, generando ideas para cada una de las preguntas a responder. Cada equipo iba poniendo las ideas en el tablero virtual creado en Fun Retro, todas ellas estuvieron identificadas por el nombre del equipo. El tablero virtual fue poblándose dinámicamente a medida que avanzábamos en la retrospectiva, así pudimos ir viendo en tiempo real las aportaciones de todos, con posibilidad de complementarlas y/o unir propuestas similares.

Imagenes del tablero de la retro

Una vez que cada equipo terminó de generar ideas y dar feedback a las preguntas, procedimos a votar distribuyendo 3 puntos por persona por cada columna de la retrospectiva.

Tablero finalizado

Actividad final de conclusiones

Para finalizar el taller hicimos algo muy enriquecedor: nos reunimos todos los equipos y compartimos lo que nos había parecido la experiencia, los aprendizajes alcanzados, los consejos y anécdotas de retrospectivas distribuidas vividas por varios participantes, incluyendo cuando participan equipos deslocalizados en varios países y João hizo una síntesis de lo que hay que tener en cuenta para hacer retrospectivas distribuidas. De esta actividad final los aspectos y/o conclusiones más importantes que surgieron fueron:

  • Por lo general, en las retrospectivas distribuidas lograr una comunicación efectiva y de calidad es muy difícil. Quizás es porque nos estamos basando en cómo se hacen las presenciales. Sería bueno pensar en cómo hacer retrospectivas distribuidas sin tener como base las presenciales, sino definir un diseño propio tomando en cuenta las particularidades y las dificultades que poseen.
  • Es muy importante hacer actividades de engagement antes de comenzar las retrospectivas distribuidas, para aumentar el conocimiento personal de los miembros de los equipos y de sus particularidades culturales.
  • Es bueno que los miembros del equipo se conozcan presencialmente en algún momento y si es posible compartan tanto dentro como fuera del ámbito laboral, para crear conexiones personales más fuertes y un mayor nivel de confianza.
  • Es muy importante tener un facilitador de la retrospectiva en cada uno de los sitios que intervengan, y que estén coordinados entre sí.
  • Es importante tratar de unificar los comportamientos de los equipos en cada uno de los sitios.
  • Muchas veces hay problemas de horarios, sobre todo cuando hay equipos en distintos países. Hay que llegar a acuerdos, porque por lo general algún equipo se ha de sacrificar ya que tendrá que participar fuera de su horario laboral. Una idea es que se rote este “sacrificio” para que no sean siempre el mismo equipo el afectado.
  • Otro problema, al trabajar con equipos de varios países, es que al hablar en un idioma que no es el nativo se limita la capacidad de expresión, así como el uso de expresiones locales o modismos que no son entendidos por todos los miembros del equipo. Por eso es bueno hacer una labor de concienciación con respecto a la manera de comunicarnos en las retrospectivas distribuidas.
  • Un tema de vital importancia son las diferencias culturales entre equipos de distintos países y culturas, diferencias que pueden llevar a problemas y malentendidos. Una buena práctica para mejorar este aspecto es la realización de actividades de engagement cultural, donde se tenga un tiempo para compartir aspectos específicos de cada uno de los países que participan y de su cultura.
  • Para realizar retrospectivas distribuidas hay que tener infraestructura tecnológica, necesaria para que funcionen.
  •  La tecnología puede fallar por lo que siempre hay que tener un plan B y hasta un plan C.
  • Tener una agenda definida previamente y compartida antes de hacer la retrospectiva.
  • Tener el objetivo de cada dinámica visible en todo momento.
  • Usar cámaras permanentes.
  • Se tarda más en prepararlas y es mucho más complicado que una retrospectiva presencial, por lo que es bueno tener un coordinador/facilitador en cada sitio y trabajar de manera conjunta.
  • Hay que manejar el solapamiento de conversaciones, los ruidos ambientales y la concentración y la participación en la retrospectiva. Por esto también es bueno tener un facilitador local.
  • Otras herramientas que se pueden usar en Retrospectivas Distribuidas:
  • Videocofenercia: Zoom
  • Tablero virtual compartido: StormBoard, Ideaflip, Retrium y Realtimeboard

Y como conclusión general podemos decir que fue una experiencia inmensamente enriquecedora al poder vivenciar lo que es una retrospectiva distribuida, las cosas que pueden pasar, cómo solucionarlas y el poder compartir nuestras experiencias y aprendizajes. Muchas gracias a los organizadores, facilitadores y a todos los que participamos 🙂

grupo del taller

Gertru y Alex

Post escrito conjuntamente por Gertrudis López y Alexander Menzinsky

Anuncios

Traducción al castellano del post “50 Best Scrum Practices for Dream Team” de Kevin Wood

El otro día estábamos compartiendo un post de Kevin Wood, publicado en febrero de este año, que nos habla de las 50 mejores prácticas de Scrum (50 Best Scrum Practices for Dream Team) y nos pareció tan útil y tan relevante para cualquiera que esté involucrado con Scrum que decidimos traducirlo al castellano para que todos los interesados puedan tener acceso a él. Aquí os compartimos nuestra traducción:

Batman y Robin

Scrum es uno de los frameworks más populares para implementar Agile. De hecho, muchas personas creen que Scrum y Agile son la misma cosa, aunque definitivamente no lo son. Agile es un grupo de metodologías de desarrollo de software basado en el desarrollo iterativo, y Scrum es un subconjunto de Agile pero con sus propias peculiaridades debido al compromiso con iteraciones cortas.

Con Scrum, los productos se construyen en una serie de iteraciones de longitud fija (sprints). Esto permite a los equipos entregar software a intervalos regulares, recibir retroalimentación rápida y adaptarse rápidamente a los requisitos cambiantes.

Aquí se presenta una lista de las mejores prácticas de Scrum que han demostrado su efectividad para ayudar a mejorar la calidad y aumentar la productividad, para entregar un producto que aporte valor y que cumpla con los objetivos de negocio.

Equipo

  • Los miembros del equipo trabajan en roles multifuncionales
  • El equipo tiene el equilibrio adecuado entre los desarrolladores y el QA (2: 1 o 4: 1)
  • Los miembros del equipo colaboran para entregar en primer lugar historias de alta prioridad
  • Los miembros del equipo piden ayuda proactivamente
  • Los miembros del equipo se dan feedback constructivo mutuamente y de manera oportuna

Scrum Master (SM)

  • El SM facilita la autoorganización del equipo
  • El SM se enfoca en remover impedimentos (problemas de recursos, problemas o desobediencia en la implementación de prácticas de scrum)
  • El SM protege al equipo de distracciones externas e internas
  • El SM permite una estrecha cooperación en todos los roles
  • El SM interactúa con la alta dirección

Propietario del Producto (PP)

  • El PP interactúa con el equipo y todas las partes interesadas (Stakeholders) para crear el
    backlog
    o la Pila de Producto
  • El PP escribe historias de usuario y criterios de aceptación
  • El PP prioriza la Pila de Producto y decide sobre las fechas de lanzamiento de las diferentes versiones
  • El PP acepta o rechaza historias de usuario
  • El PP cancela el sprint si piensa que el objetivo del sprint ya no tiene sentido

Definición de Hecho o Definition of Done (DoD)

  • Cada historia de usuario cumple los criterios del DoD
  • Todos los miembros del equipo y el PP conocen de memoria el DoD y lo respetan

Estimación

  • El PP obtiene estimaciones a partir del equipo
  • Sólo estima el equipo
  • Cada miembro del equipo participa en la estimación
  • El equipo estima usando la técnica del Planning póker

Reunión de planificación Sprint

  • Todos los miembros del equipo participan
  • El PP presenta las historias de usuario priorizadas al equipo
  • Todas las historias del sprint están estimadas
  • La reunión da como resultado un plan de sprint

Sprint

  • El equipo entrega algo después de cada sprint
  • El equipo sigue las prioridades marcadas por el PP
  • El equipo alerta al PP cuando tienen problemas
  • El equipo trata los problemas cuando ocurren (no más tarde)
  • La longitud de Sprint no cambia después de cada sprint
  • Las historias que se han empezado terminan dentro del mismo sprint

Pila de Sprint (PS)

  • La PS está visible y es de fácil acceso para el equipo
  • La PS se actualiza todos los días
  • Las estimaciones de las tareas se actualizan todos los días
  • Los miembros del equipo actualizan la PS por ellos mismos
  • Las historias están claramente mapeadas

Scrum Diario (SD)

  • El SD tiene ocurre a la misma hora y lugar todos los días
  • El SD comienza y termina puntualmente
  • Todos los miembros del equipo están involucrados
  • El PP participa en la reunión por lo menos unas pocas veces por semana
  • El equipo revisa el gráfico de burndown y toma medidas si van retrasados
  • El SD dura como mucho 15 minutos – todas las discusiones tienen lugar después

Revisión de Sprint

  • La demo formal se realiza después de cada sprint
  • Sólo las historias aceptadas por PP se demuestran
  • Todos los interesados se han invitado para la demo con antelación
  • Se anima a las partes interesadas a dar su opinión durante la demo

Retrospectiva

  • La Retrospectiva tiene lugar después de cada sprint
  • Todos los miembros del equipo y el PP comparten el feedback
  • El equipo analiza los datos y decide que acciones emprender
  • Las acciones se priorizan e implementan en los próximos sprints

Sobre el autor

Kevin Wood es Gerente de Desarrollo de Atlaz y tiene una gran experiencia en finanzas y administración de negocios. Su profunda comprensión de los principios de mercadotecnia y sus excelentes habilidades analíticas, le ayudan a identificar ideas de tendencia, a evaluar riesgos y a encontrar los mejores potenciales para las necesidades y metas de sus socios.

Esperamos que os sea de utilidad y vuestros comentarios

Post escrito conjuntamente por Gertrudis López y Alexander Menzinsky

¿Cómo calcular la capacidad de trabajo de un equipo Scrum?

Esta es una pregunta que hacen frecuentemente los participantes en el curso troncal OKs de Scrum Manager y es un punto donde, por lo general, hay muchas dudas y algunos no se atreven a preguntar. En este post trato de recoger una respuesta lo más sencilla posible y que a su vez de pie para seguir profundizando y ahondando en el tema.

La capacidad de trabajo de un equipo Scrum es la cantidad de trabajo que puede hacer el equipo en un sprint y se puede tener una estimación de este en función de la del promedio de la velocidad del equipo en sprints anteriores, el promedio de la velocidad x persona x dia  y de los días efectivos de trabajo que va a haber en un sprint.

El concepto base a tomar en cuenta es el de velocidad, que en Scrum, es la cantidad de trabajo que puede realizar el equipo en un sprint. La cantidad de trabajo se suele medir en tiempo ideal o en puntos (se explican en el capítulo de Medición y Estimación ágil del manual del curso troncal de Scrum Manager).

Ahora bien, ¿Cómo calculamos la capacidad de trabajo de un equipo para un sprint que va a comenzar?

Para calcular la capacidad real del equipo en un sprint, de manera general, se puede tomar como base la velocidad promedio del equipo obtenida de sprints anteriores (o la del sprint anterior o un consenso del equipo según las condiciones que prevea para el sprint a estimar)* y la velocidad promedio del equipo x Persona x Día (*) y se consideran los siguientes factores:

a – Número de personas en el equipo
b –  Número de días totales de trabajo en el sprint
c – Número de días del sprint que se van a dedicar a reuniones (reuniones de planifiación, revisión, retrospectiva y refinamiento de la pila de producto)
d- Días efectivos del sprint, en este caso (b-c)
e – Días persona disponibles (d x a)
Con base en esto, la capacidad estimada del equipo en el próximo sprint sería: Velocidad promedio del equipo x persona x dia) x Días persona disponibles (e).

Supongamos que tenemos un equipo de seis personas, que hace sprints de 2 semanas (10 días) y que su velocidad promedio es de 153 puntos x Sprint y la velocidad del equipo x persona x día es de 3 puntos.

Vamos a calcular la capacidad del equipo para el siguiente sprint donde hay un día no laborable. Tendríamos entonces:

a – Número de personas en el equipo, supongamos 6 personas
b –  Número de días totales de trabajo en el sprint, 9 días
c – Número de días del sprint que se van a dedicar a reuniones (reuniones de planificación, revisión, retrospectiva y refinamiento de la pila de producto), supongamos 1,5 días**.
d – Días efectivos del sprint, en este caso, 7,5 días (9 días totales – 1,5 días de reuniones)
e – Días persona disponibles, en este caso 45 días personas/sprint (7,5 días x 6 personas) (Este es el caso ideal donde no hay nadie de vacaciones y todos los miembros tienen una dedicación del 100% y el grado de experiencia de cada miembro del equipo es la misma. Si no es así, hay que tener en cuenta este tipo de cosas para saber los días persona disponibles)

Con base en esto, la capacidad estimada del equipo en el próximo sprint sería de 135 puntos (3 puntos x 45 días persona por sprint (e))

Ahora, si vamos a hacer esta estimación para el primer sprint, para el que no tenemos datos previos, tenemos que hacer asumir ciertas cosas, y hay varias formas de hacerlo. Jorge Abad en este post, explica muy bien distintas formas de cómo hacer esto.

Es de hacer notar que una de las características de las estimaciones ágiles es que son aproximadas y como se hacen con el criterio de juicio de expertos, ya que las hace el equipo, las aproximaciones tienen un alto grado de confiabilidad, pero siguen siendo aproximaciones para tener una guía, nada está escrito en piedra.

**: En este post de Jorge Abad vemos una tabla con los tiempos estimados para las reuniones según la duración del sprint, basado en la Guía de Scrum.

Espero que os sea de utilidad y vuestros comentarios

Saludos

Gertrudis

 

Jugando Cynefin Lego Game en el Road to BAOS 2017

Siguiendo 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

¿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 praticar estimationatscale con todos vosotros.

Deseamos que el post os sea de utilidad y esperamos vuestros comentarios

Gertru y Alex

Post escrito conjuntamente por Alexander Menzninsky y Gertrudis López

Mapa mental del post: “7 SCRUMMASTER ANTIPATTERNS THAT EVERY SCRUMMASTER MUST UNDERSTAND” de Luis Gonçalves

Estoy preparando una formación para Scrum Masters y uno de los puntos que me parece fundamental tratar es el de los antipatrones que se presentan frecuentemente en las organizaciones y en las implementaciones de Scrum con respecto a este rol.

Pienso que es importantísimo tratar este tema en las formaciones y reuniones de Scrum Masters para abordarlo tanto de manera preventiva como también post-mortem, es decir, una vez que se ha presentado alguno de los antipatrones, para poder ser capaces de prevenir su aparición siendo conscientes de su existencia y de sus características y en el caso de detectar su presencia poder tomar las acciones necesarias para corregir dicha situación.

Para tratar el tema me gusta un post de Luis Gonçalves: “7 SCRUMMASTER ANTIPATTERNS THAT EVERY SCRUMMASTER MUST UNDERSTAND”, que me parece supercompleto y práctico, ya que habla de los principales antipatrones que se dan en las organizaciones con respecto al rol del Scrum Master, debido principalmente al desconocimiento por parte de la organización de la importancia de este rol en las implementaciones de Scrum y también al desconocimiento y/o falta de puesta en práctica del enfoque de “Servant Leader” (Líder al servicio del equipo de desarrollo, del Product Owner y de la organización) por parte de los mismos Scrum Masters.

Aunque el título hace referencia a siete antipatrones, en la última actualización del post, Luis identifica y describe ocho antipatrones asociados al rol de Scrum Master:

  1. “Scrum Master” en vez de “Jefe de Proyecto”
  2. Mezcla de roles “Scrum Master” y “Product Owner”
  3. Falta de enfoque
  4. Scrum Masters que no hacen coaching a la organización
  5. Scrum Master sólo como secretaria
  6. Scrum Masters que no hacen coaching al Product Owner
  7. Scrum Master no reconocido por la gerencia
  8. Cambiar frecuentemente quien ejerce el rol de Scrum Master

Para entender en profundidad cada antipatrón y tener una base de discusión sobre el tema, he elaborado un mapa mental en la herramienta colaborativa Mindmeister que los resume y que permite ver de una manera esquemática cada antipatrón y sus elementos: cuando se puede presentar, los problemas que puede ocasionar y posibles soluciones. Haciendo click aquí o sobre la imagen podéis acceder al mapa en el Mindmeister y ver el detalle de cada uno de los antipatrones.

Imagen del Mapa mental de antipatrones del Scrum Master

Imagen del mapa mental en castellano del post “SCRUMMASTER ANTIPATTERNS THAT EVERY SCRUMMASTER MUST UNDERSTAND” de Luis Gonçalves

Comparto el mapa mental en el blog porque pienso que os puede ser de utilidad y servir como base para formaciones, retrospectivas e intercambio de ideas sobre el tema con el objeto de generar discusiones, reflexiones sobre si se está dando algún antipatrón, posibles formas de resolverlos y el descubrimiento de otros antipatrones no incluidos aquí.

Espero vuestros comentarios

Saludos Cordiales,

Gertrudis López

 

Haciendo retrospectivas con LEGO

El año pasado escribí un post donde compartía un mapa mental sobre una técnica para hacer retrospectivas con LEGO, propuesta por Dominic Krimmer en su post en el blog de Luis Gonçalves “LEGO a great tool for your Agile Retrospectives”

Ahora quiero compartir una experiencia al aplicar la técnica en una de nuestras retrospectivas en un equipo ágil donde estamos trabajando en un proyecto de investigación y desarrollo. Esta retrospectiva la hicimos para el tercer sprint; en los sprints anteriores habíamos usado la técnica de los cuatro cuadrantes donde dijimos qué fue bien, qué fue mal, ideas para mejorar y acciones concretas a tomar para el próximo sprint.

Para el equipo fue una gran sorpresa el hacer la retrospectiva con LEGO y a la vez despertó enormemente su curiosidad por lo que iba a pasar y por lo que íbamos a lograr. Este era uno de mis objetivos: hacer la retrospectiva de manera diferente a lo que habíamos hecho antes, despertar su curiosidad y engancharnos a la actividad.

img_20170127_140702

Lo primero que hicimos fue crear una figura que reflejara el último sprint. Cada uno habló de su figura y se generaron discusiones para encontrar exactamente cuales eran las preocupaciones de cada uno. Estas fueron las figuras que reflejaban el último sprint:

img_20170127_141757

Esta figura representa uno de los objetivos logrados en el sprint: comunicar dos entornos para la ejecución de pruebas y que la forma de comunicación, representada por la escalera, era todavía inestable.

img_20170127_141739img_20170127_142222

Esta figura (se muestran dos imágenes de la figura, la segunda imagen es un zoom de la primera) representa el estado actual en donde se ve el miembro del equipo, en la mitad de un camino con barreras que ha ido superando, con amenazas a su alrededor (representadas por el perro) y con barreras por superar.

img_20170127_142144

Esta figura refleja al equipo en el sprint actual, con un inicio desde cero al comenzar y habiendo cruzado un puente (estrecho y difícil) que ha llevado al equipo a un nivel superior de conocimiento y práctica en el ámbito del proyecto y con otro puente por cruzar que conducirá a la visión que se quiere alcanzar.

Con todas estas figuras podemos darnos cuenta del poder de los LEGOs para expresar ideas complejas. Pienso que la profundidad del significado de las figuras es mucho mayor que la profundidad que se puede obtener escribiendo ideas en post-its y por lo tanto la profundidad de las discusiones y reflexiones surgidas a partir de las figuras fue muy grande, lo que las hicieron muy enriquecedoras para que cada miembro pudiera entender la visión y las preocupaciones de sus compañeros.

En la segunda parte de la retrospectiva cada uno construyó lo que consideraba el próximo paso importante para el equipo con el objetivo de mejorar y estas fueron las figuras resultantes:

img_20170127_143522

Lograr una forma de comunicación sólida de las plataformas involucradas en el proyecto.

img_20170127_143504

Enfrentar las amenazas que se nos presenten en el camino juntos cómo un equipo.

img_20170127_143453

Contar con el apoyo de una infraestructura sólida que nos permita trabajar mejor y con personas con más experiencia en el ámbito del proyecto para facilitar el camino que queda por recorrer.

Al igual que en la primera parte de la retrospectiva se generaron discusiones muy ricas sobre las posibles acciones de mejora que reflejaban las figuras y se acordó buscar la manera de implementarlas a lo largo de los siguientes sprints.

Como conclusión general, la experiencia fue muy divertida, creativa a innovadora. Permitió a cada miembro del equipo expresarse de una manera diferente, haciendo que los más introvertidos pudieran tener una manera más poderosa de expresarse. El jugar hace que haya una liberación de muchas barreras que coartan la expresión de las ideas en los entornos laborales tradicionales y el poder dar rienda suelta a la imaginación y a la creatividad, construyendo una figura que refleje lo que piensas y lo que sientes a la vez, hacen que surjan expresiones muchos más ricas, más rompedoras y con más capacidad de llevar al equipo a una profunda reflexión sobre cómo han trabajado y cómo conseguir grandes mejoras. Una experiencia recomendable al 100%.

Espero a que os animéis a hacer retrospectivas con LEGO y a compartir vuestras experiencias.

Saludos

Gertrudis

PD: Muchas gracias a Paco y a Carlos por formar parte de este maravilloso, creativo e innovador equipo