miércoles, 6 de diciembre de 2017

¿Cómo hacer una retrospectiva distribuida con equipos deslocalizados?


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 el Café Teatro, un lugar superculturoso con un entorno propicio para el arte, la inspiración, la innovación y la creatividad.
El Matadero Madrid y el Café Teatro
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.
Equipo "CoraBAOS" Equipo "Glaciar" Equipo "CoffeePanda"
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:






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 la pantalla para mostrar presentaciones, fotos u hojas de cálculo.



Fun Retro proporciona 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 personalizar 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 pueden 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.
Tablero virtual Fun Retro de la retrospectiva poblándose a medida que avanza el taller
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.
Pantallazo del tablero virtual Fun Retro una vez finalizada la retrospectiva distribuida
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 sea 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 amplio. 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 son mucho más complicadas que las retrospectivas presenciales, 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:
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 :)
Nuestros agradecimientos a todos los participantes del taller
Post escrito conjuntamente con Gertrudis López, link al post en su blog "Agile: lo bueno, lo feo y lo malo"
Publicado por en 2 comentarios:

lunes, 4 de diciembre de 2017

¿Cómo mostrar el impacto de la deuda técnica en una simulación de Scrum?

Este es un ejercicio del curso CSD de
La deuda técnica ha de gestionarse
En este post quiero presentar un juego pensado para desarrollar en noventa minutos, en el que los participantes practican cómo incorporar historias técnicas en la planificación de sprint y así reducir la deuda técnica y mantenerla bajo control durante el proyecto.

 El objetivo del juego es que el equipo de desarrollo ponga de relieve el valor que aporta resolver deuda para el Propietario del Producto, y balancear historias de usuario y técnicas para maximizar el valor entregado al cliente a largo plazo. Este juego proporciona al equipo el espíritu de colaboración necesario para organizarlo en su propia organización con el Propietario del Producto y mostrar la importancia, para el éxito del proyecto, de la incorporación de historias técnicas que ayuden a disminuir la deuda técnica existente.

La deuda técnica prudente nos hace ser ágiles

Material del juego

El juego incorpora las historias de usuario que tratan funcionalidades para la construcción de una tienda de venta on-line e historias técnicas que implementan técnicas ágiles como integración continua, refactorización y pruebas automatizadas.

Este juego ha sido inspirado en el "The Technical Debt Game de David Croley de Agile Velocity.

He incorporado una serie de variaciones para incorporar elementos para una simulación de Scrum más pedagógica y completa.

Para el juego hacen falta 5 personas, un rol de Propietario del Producto y 4 miembros de equipo. El trainer o facilitador, experto en el juego, hará de Scrum Master. Las tareas del Propietario del Producto serán las rellenar la hoja de registro y de negociar con el equipo la deuda técnica a incluir en el sprint según las siguientes directrices:
Las tareas del equipo serán las de debatir las historias de usuario y deuda técnica a incluir y ejecutar la simulación de cada sprint.
Paso 0

Dibujar el tablero sobre una hoja de rotafolios:
Tablero scrumboard del juego que incorpora la deuda técnica
Paso 1

Hoja de registro marcada con el área cumplimentada en cada paso
Calcular la capacidad del equipo, para ello el Propietario del Producto sumará el impacto de la deuda técnica que afecta a los sprints (sección B). El impacto lo apuntará en la hoja de registro en la fila del impacto y la resta entre la capacidad teórica y el impacto en la capacidad actual para el sprint.

Paso 2
Paso 3
  • Cada miembro jugará una tirada de dado por cada uno de los cinco días de la semana, una tirada representará los puntos realizados por persona/día.
  • Los puntos de dado se aplicarán primero para absorber el total del impacto de la deuda técnica vigente.
  • Los puntos de dado restantes se aplicarán restando al coste de las historias de usuario y deuda técnica y se moverán a la columna "En curso" (Sección D). Si el coste queda a 0 se pasarán a la columna "Finalizado" (Sección E).
  • El Propietario del Producto anotará el total del equipo en el día correspondiente en la sección de la ejecución del sprint.
Paso 4

Acabado el sprint:
Alumnos en plena ejecución del juego
Paso 5
Tablero scrumboard del juego en curso
Debate final

 Con el gráfico delante el equipo sacará conclusiones sobre cómo ha gestionado la deuda técnica y que mejoraría para la próxima partida.
Hoja de registro con los diferentes gráficos de evolución
Observando la hoja de registro de un juego real podemos ver las diferentes evoluciones del juego:
Descargas / Downloads
Primera iteración del juego
A principios de 2015 impulsado por mi compañero Miguel para crear un curso que tratara la deuda técnica, y habiendo visto el artículo de David Croley, me animé a crear la primera versión del juego. Mis compañeros de entonces me apoyaron en las primeras partidas y me dieron su feedback.

 Experimentaron como equilibrar la deuda técnica con las historias de usuario, y cómo resolverla les permitía aumentar la velocidad, y como si no lo hacían acababan ahogados por la misma. Recuerdo que comentario que experimentaron lo que todos los equipos de Scrum; los equipos noveles son optimistas y tienen la tendencia a meter mas en los sprints de lo que pueden afrontar.
Gracias chicos por jugarlo por primera vez y dar feedback, gracias Javier, Roberto y Juan
Publicado por en No hay comentarios:

domingo, 3 de diciembre de 2017

¿Se puede utilizar una retrospectiva para hacer team-building?

Grupo en etapa de formación de equipo
De hecho las retrospectivas son un evento que de por si hace team-building, pero puede que en alguna situación necesitemos hacer una retrospectiva dirigida especialmente a darle dirección e identidad al equipo de desarrollo.

 Me encontré con una situación en la que de un equipo que funcionó exitosamente con Scrum, solo quedaron dos miembros originales, y en el que se incorporaron a posteriori cuatro profesionales nuevos. Después de mes y medio trabajando juntos no habían recuperado el ritmo del equipo original. Observándolos me di cuenta que la carencia estaba en la falta de unidad, confianza y autoorganización.

 Cuando de forma disruptiva un equipo se ve reducido a la mitad y se incorporan nuevas personas, ocurre que los miembros originales sienten frustración. Con los miembros nuevos no hay la confianza como con los de siempre, no tienen el mismo conocimiento compartido y por otro lado se produce un sentimiento de pérdida de pertenencia a un equipo que una vez fue ganador. También está el pasar del tiempo que idealiza la cosas, nos olvidamos de los malos momentos, y de forma inconsciente ponemos resistencia a la aceptación de los nuevos miembros. Es necesario que los miembros del equipo original pasen su duelo antes de formar equipo con los nuevos. Estos últimos por supuesto notan todo esto y a su vez se comportan con matices de a la defensiva, con lo que el proceso de formación de equipo se hace más arduo y se hace necesario un buen acompañamiento de un Scrum Master experimentado.

 Decidí cambiar la técnica de la retrospectiva para enfocarla sobre el equipo e intentar desvelarles aquellas cosas que quisieran llevarse a su relación como equipo. Para ello me basé en una técnica de coaching para desvelar bordes dobles que ayuda a los equipos en los cambios que les sobrevienen y a encontrar su camino.

 El tablero tiene 4 columnas que se pueblan de forma secuencial, trabajándolas de una en una:
  • ¿Qué somos? Igual que en otras técnicas de retrospectiva los asistentes escriben en post-its, esta vez todo aquello que sienten que son como equipo. Cuando buscan lo que son están buscando cosas que tienen en común y que les unen, eso es una buena base para empezar a encontrar su camino. Una vez escritos los post-its estos se pegan de uno en uno en la columna y cada miembro explica lo que ha escrito. Dado que esta retrospectiva va directa a la parte emocional de las personas cabe no esperar demasiados post-its, ni que todos los miembros participen. Es cuando conversan sobre alguno de los post-its es donde se ve la potencia de la técnica, es cuando se desbloquean y sus conversaciones se vuelven vivas e impregnadas de profundidad emocional.
  • ¿Qué no somos? Una vez concluida la pregunta anterior los asistentes escriben post-its con lo que consideran que no son. Es una pregunta difícil, aunque ellos saben perfectamente lo que no son y qué fuera deseable ser, es algo difícil de expresar cuando la identidad del equipo no esta formada. Les podemos ayudar diciéndoles que recuerden equipos en los que participaron y fueron excelentes, aquellos con personas con las que volverían a formar equipo sin dudar.
  • ¿Qué no somos que quisiéramos ser? Esta es la pregunta clave en la que habiendo convergido en lo que no son, emerge lo que pueden y quieren ser. Podemos decirles que cierren lo ojos y se visualicen en el futuro, piensen en cómo se ven como equipo a un año vista. Que miren alrededor, huelan el ambiente, escuchen lo que les rodea... y que escriban aquello que hace especial a ese equipo del futuro.
  • Plan de acción: En la fase final de la retrospectiva los asistentes buscan planes concretos para todo aquello de la columna anterior que sea susceptible de poner en marcha, esas son las mejores acciones desde dentro para un team-building exitoso. Como Scrum Master podemos aprovechar y reforzar Scrum explicando como los objetivos de los eventos de Scrum propician la formación de equipos integrados y ganadores.
Ejemplo del resultado de una retrospectiva de team-building
Siempre pongo una columna de agradecimientos, esta crea mucha energía positiva que desbloquea posibles reticencias con cada post-it que se le agrega.
Publicado por en 2 comentarios:

miércoles, 29 de noviembre de 2017

¿Cómo hacer visibles las interrupciones a las que está sometido un equipo?

Cada globo representa una interrupción - cortesía de Pixabay
Uno de los beneficios de la Agilidad y la mentalidad ágil es que ambos dan visibilidad a todo: a lo que queremos construir, a lo que se está construyendo, a los éxitos, a los fracasos, a los aprendizajes, a los problemas e impedimentos, etc.

 Como sabemos, uno de los desperdicios o mudas más corrientes son las interrupciones que sufren tanto los miembros de los equipos como los demás roles de Scrum.

Para dar visibilidad a las interrupciones lo que hemos hecho, es que cada vez que alguien sufre una interrupción, este infla un globo y lo deja errando por el suelo. Al cabo de una semana tuvimos una representación muy visual del volumen de interrupciones acaecidas. Contando el número de globos, y en base a una media de 15 minutos perdidos por interrupción, el tiempo medio que las personas necesitamos para cambiar de contexto, es muy fácil hacer números y calcular el coste que representan. Esos números son muy poderosos, los podemos exponer cuando como Scrum Master hayamos de tratar con aquellos que son propensos a interrumpir.

 Mi compañero Marcos Garrido fue quién me enseñó esta técnica y me contó su experiencia. Entró uno de los jefes del área en la sala, vio los globos y preguntó si estaban celebrando un cumpleaños, le dijo que no... y le explicó de lo que se trataba. El jefe recibió el mensaje en todo su esplendor, en poco tiempo el número de interrupciones se redujo drásticamente. Más tarde el jefe le pidió a Marcos que no volviera a utilizar mas esta técnica, jajaja... ¡funcionó!
Publicado por en 5 comentarios:

domingo, 26 de noviembre de 2017

¿Qué hacer cuando el equipo diverge repetidamente en la estimación de una historia de usuario?

Equipo estimando, la mayoría converge hacia el 5 pero uno se estanca en el 21
La estimación de historias de usuario la deben de realizar las personas que van a realizar el trabajo, por tanto el equipo, y solo el equipo, debe estimar.

Al ocurrir de forma colaborativa trae varias ventajas consigo, como lo son incorporar los diferentes puntos de vista y opiniones de todos, detectar posibles tareas ocultas y posibles obstáculos, tener estimaciones más acertadas y compartir y alinear el conocimiento de todos.

Pero la colaboración también trae consigo el conflicto, y a veces, sobre todo en los equipos recién estrenados en Scrum y planning poker, no consiguen ponerse de acuerdo en una estimación. Después de la segunda o tercera jugada sobre la misma historia de usuario no consiguen converger en una estimación compartida.

 En ese punto suele surgir la duda de si la estimación colaborativa con planning poker es de utilidad, afirman que es mejor que estime directamente el experto y se preguntan para qué sirven las estimaciones de los inexpertos... Les suelo plantear la reflexión de si siempre van a querer depender de ese experto, y de si no resulta beneficioso hacer que todos los miembros del equipo reflexionen acerca de la historia de usuario, y que poco a poco vayan adquiriendo conocimiento y experiencia para así ir mejorando sus estimaciones conjuntas.

Un ejemplo clásico es cuando estiman una historia y las estimaciones son dispares, tenemos por ejemplo un 5, un 8 y un 21 como en la imagen. Destapadas las cartas entran en conversación para descubrir qué es lo que sabe uno de ellos que los demás no saben. Vuelven a jugar y esta vez salen dos 5, pero el mismo 21 de la jugada anterior sigue saliendo.

 Aún habiendo jugado dos veces siguen divergiendo, probablemente porque el significado del punto de historia no lo han interiorizado todavía como equipo y aún no representa un mismo tamaño/esfuerzo para todos ellos. Lo que debemos de hacer es saltarnos la historia de usuario conflictiva, seguir estimando las siguientes historias para normalizar el punto de historia y que vayan convergiendo. Más tarde podemos volver a la historia conflictiva, lo más probable es que esta vez si obtengan una estimación con la que todos estén de acuerdo y se sientan comprometidos.
Publicado por en No hay comentarios:

jueves, 23 de noviembre de 2017

¿Cómo actuar si el Scrum Master se da cuenta que el equipo está en una esfera?

Equipo trabajando su esfera - gracias coaches :-)
¿Quienes no hemos estado alguna vez dentro de una esfera? Ocurre algo que no podemos manejar, nos sentimos abrumados y exhaustos y nos colapsamos en una esfera en la que nos encerramos, un mundo pequeño, íntimo, personal y cerrado. Dentro de nuestra esfera nos sentimos protegidos y seguros, en ella no somos capaces de recibir mensaje alguno del exterior y todo pensamiento justifica los pensamientos originales en los que estamos embuclados. La esfera resulta en un campo emocional encapsulado que hace de muro opaco hacia el exterior.

También los equipos pueden entrar en una esfera. Se percibe en su campo emocional, su esfera despide una energía rara, todo es pesado, desconsolado, cerrado, hablan todo en negativo.

Estuve en un empresa que tenía alrededor de 200 ingenieros informáticos trabajando en su sede, y que en una decisión "estratégica" cambió el modelo e hizo volver a los externos (subcontratados) a las sedes de sus consultoras para realizar su trabajo desde allí. Algunos de los equipos desplazados trabajan con Scrum y yo actuaba de coach ágil en un par de ellos.

Uno de mis equipos entró en una esfera, se embuclaron con que el proyecto iría muy mal, que su empresa ni el cliente cuidaba de sus empleados... en realidad tenían miedo ante el cambio y a perder su trabajo.

Me di cuenta de ello cuando noté resistencia, comencé desvelando y nada funcionaba, todo lo que les decía rebotaba en ellos, a todo había una respuesta "¡No!... porque...".

Me basé en las técnicas de trabajo con esferas del modelo de coaching de organizaciones y sistemas relacionales ​ORSC™ para tratar al equipo. Empecé explicando al equipo lo que es una esfera, revelarles que estaban dentro de una y a hacerles conscientes de sus posibilidades. El mero hecho de ponerle nombre a lo que está pasando y normalizarlo les alivió y soltó mucho.

La esfera "sumidero de almas"
Cortesía de Pixabay
Lo interesante de las esferas es que se desvanecen solas, solo es cuestión de tiempo. Más tarde después de la comida ya pudieron hablar de sus miedos y trabajar un plan de acción.

Preguntas con las que podemos ayudar a los equipos a identificar las esferas y a darles herramientas para evitar entrar en ellas:
  • ¿Qué es lo que os lleva a esa esfera?
  • ¿Qué convicciones habitan en vuestra esfera?
  • ¿Qué tiempo hace allí?
  • ¿Cómo os ayuda esa esfera?
  • ¿Cómo podéis cuidar de vosotros mismos cuando entráis en la esfera?
  • ¿Qué os ayudaría a evitar en esa esfera?
El equipo aprendió a darse cuenta cuando se acercan a una esfera, cuando se notan callados y decaídos la identifican y aprendieron a evitarla mencionando que el "sumidero de almas", que es como la habían bautizado, estaba asomando la cabeza.

 Quiero dar mis agradecimientos a Linda Berlot quien me dio las enseñanzas sobre las esferas :-)
Publicado por en No hay comentarios:
Suscribirse a: Entradas (Atom)