domingo, 10 de diciembre de 2017

¿Cuál es el talón de Aquiles de SAFe?

Tuve una conversación con Marcos que no me dejó impasible. Ya sabéis que creo en SAFe y me gusta, creo que es un marco Agile y Lean hasta la médula, pero Marcos fue capaz de arrojar una nueva luz a mis principios. 

Si lo miramos con detenimiento Scrum trata de simplificar la complejidad, una empresa es Agile cuando ha simplificado sus estructuras organizativas y funciona de forma plana y fractal.

En cambio SAFe es un marco complejo que trae complejidad, por tanto no pone el foco en la simplicidad como lo hace Scrum. Recordemos el décimo principio del Manifiesto Ágil:

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

SAFe sustituye la complejidad organizacional y jerárquica de una compañía por una complejidad Agile y Lean, pero no simplifica, y si no simplifica ¿no va a atar a la empresa a SAFe y a su complejidad? Esto hace cuestionarnos si la empresa que implante este marco pueda tener la oportunidad de ser Agile puro, y si esta va a tener la oportunidad en el futuro de ir más allá de SAFe. Con SAFe lo que puede ocurrir es que se mantenga atascada en un nivel de complejidad similar al de antes de la transformación...

En mi realidad las empresas que pueden ser Agile ya lo son, ahora estamos lidiando con empresas que nunca serán Agile de verdad, grandes compañías y consultoras con cientos de empleados que difícilmente pueden apostar por la persona y empoderarla en su talento. Vender Agile puro a estas empresas es difícil, SAFe tiene un big picture suficientemente complejo o "feo" para que estas empresas se interesen y haya posibilidades de implantarlo. SAFe es un punto de partida que puede funcionar para acercar la compañía a Agile, ¿pero permitirá a la empresa ser Agile de verdad?

Probablemente no, pienso que SAFe alargará la letanía de las empresas que no son conscientes de la nueva realidad del mundo VUCA, un mundo inmerso en la turbulencia del cambio. Las que sobrevivan serán Agile de verdad, e incluso Teal, pero las que no están condenadas a desaparecer sin compasión.

sábado, 9 de diciembre de 2017

¿Hay algún ejercicio que haga vivir a los asistentes como funciona la mejora continua?

Marcos facilitando el ejercicio
Estuve de co-trainer con Marcos Garrido en uno de sus cursos de Scrum, dónde para mostrar la potencia de la mejora continua facilitó un ejercicio de construcción de aviones de papel con tres sprints.

Instrucciones de como doblar una
hoja A4 para construir aviones
Cortesía de Ysangkok
Con tres sprints hay suficientes oportunidades de mejora notables para vivirlo, especialmente porque a lo largo de las iteraciones las personas se conocen en su manera de trabajar y convergen para formar equipo.

El objetivo trata en primer término de construir aviones de papel que tengan suficiente calidad para volar durante 2 segundos en linea recta, y en segundo término construir tantos aviones como sea posible.

La regla más importante es que una persona solo puede hacer un doblamiento, y después de hacerlo debe de pasar el avión a otra persona.

Los tiempos del juego son:
Tres minutos de sprint para la construcción de aviones
  • 2 minutos para la planificación de sprint en la que el equipo debe de determinar la carga en número de aviones que cree que puede construir.
  • 3 minutos de sprint para construir los aviones, el sprint incluye al tester que probará los aviones y los clasificará como OK si vuelan en linea recta durante 2 segundos, y como KO si no lo hacen.
  • Durante la revisión de sprint el trainer recoge los resultados de los aviones OK y KO en un tablero.
  • Antes del siguiente sprint el equipo dedica 3 minutos a una retrospectiva durante los que el equipo busca posibles mejoras para el siguiente sprint, con el objetivo primario de reducir a 0 los aviones KO.
Equipo en pleno doblaje de aviones
Marcos hizo la primera retrospectiva con el equipo y luego inició la planificación del segundo sprint. La segunda retrospectiva la hizo seguida de un Scrum de Scrums con un representante de cada equipo para así compartir experiencias entre equipos.

Tablero con los resultados
Como podemos observar en los resultados por equipos del tablero a la derecha, la mejoras obtenidas a lo largo de los sprints se hacen muy visibles. No es tan revelante como se ha ido incrementado el número de aviones OK, sino como han decrementado los aviones KO.

Todos los equipos excepto el B han incrementado los aviones OK, pero cabe destacar que ese equipo ha conseguido cero aviones KO en el tercer sprint, lo que constituye un éxito de la mejora continua.

Resaltar que el equipo A introdujo un cambio de diseño del avión en el tercer sprint y eso ha redundado en un mayor número de aviones KO, hubieron de aprender de nuevo.

Un mejora que nos llamó la atención fue la del equipo C, ellos se dieron cuenta que la regla de pasar a otra persona permite hacer pairing contruyendo los aviones entre dos, pasándoselo de uno a otro. La idea genial fue que hicieron pares juntando personas con la misma velocidad.

Mis agradecimientos a todos los alumnos que participaron en el ejercicio, se puede ver como quedó la clase :-D

viernes, 8 de diciembre de 2017

¿Cómo compartir conocimiento y experiencia a lo largo de toda la compañía?

Es deseable que en grandes compañía se compartan dentro de una misma disciplina formas de trabajar, técnicas y herramientas a lo largo de toda la organización. El modelo Spotify le pone el nombre de guild, o gremio, a grupos de personas de toda la organización que desean compartir conocimientos, herramientas, códigos y prácticas y se juntan para tratar sobre ello.
Gremios (guilds) como comunidades de práctica que cruzan las tribus de la organización - Henrik Kniberg & Anders Ivarsson
Un gremio es una comunidad de práctica, semejante a los chapters, pero a diferencia de estos últimos que son locales dentro de una tribu, los gremios son transversales a toda la organización.

La comunidad de práctica es una estructura social dentro de la propia organización que está formada por profesionales de la propia compañía que comparten un interés específico. Su objetivos son:
Cada gremio tiene un coordinador del gremio que organiza y facilita los eventos, espacios y necesidades. Aunque los gremios son especializados, cualquier miembro de cualquier squad de cualquier tribu puede unirse a cualquier gremio en que esté interesado.

El autor con el tablero del gremio de Scrum Masters y
coaches ágiles que ha adoptado el nombre de AgileGo
Un gremio a menudo incluye todos los chapters y sus miembros que trabajan en esa disciplina, por ejemplo, el gremio de testing incluye a todos los testers de todos los chapters de testing

Otro ejemplo es el gremio de coaches ágiles. Los coaches ágiles están repartidos por toda la organización, pero a través del gremio comparten conocimiento de forma continua y se reúnen regularmente para alinearse y colaborar en la mejora organizativa a alto nivel.

Los gremios no son fáciles de implementar, requieren un espacio físico que ha de proporcionar la compañía, algo de tiempo y motivación del grupo, y también requieren cierto grado de coordinación. Más de una vez he observado mucho empuje en la inciativa inicial al establecerse un gremio, empuje que al poco se desvanece por falta de motivación y sentido de utilidad. Aconsejaría comenzar en pequeño, identificar un problema o algo que pueda mejorarse y reunir a un pequeño grupo para tratarlo. En cualquier grupo suele haber un líder natural que le guste meterse en este tipo de berenjenales, dejar que emerja y darle empoderamiento para ser el coordinador del gremio. A que no adivináis quien va a ser el líder para la próxima sesión de AgileGo, jajajaja :-P

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 de 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

lunes, 4 de diciembre de 2017

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

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 equipo de desarrollo ponga de relieve el valor que aporta resolver deuda para el Propietario de 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 de 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 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
  • El Propietario del Producto completará el gráfico del sprint utilizando 1 color diferente para dibujar la evolución de cada uno de los siguientes valores: 
  • Si se acaba de finalizar el segundo sprint, coger 2 tarjetas de deuda técnica y ponerlas en la zona de la pila de producto que afecta al sprint (Sección B), si es el tercer sprint mover la última.
  • Coger una tarjeta de sprint (Sección F) y seguir las instrucciones.
  • Reiterar y seguir por el paso 1 hasta que se hayan completado los 5 sprints.
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, 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

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, trabajandolas 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.