Las 10 mejores extensiones para tunear tu tablero

Antes que todo, disculpen el efecto marketinero del titulo, pero me divierte mucho poner algo así!

Estoy muy alineado con Tobias Mayer cuando dice que el tablero de tareas (físico, con post-its en la pared) es el Corazón de Scrum, y con Daniel Markham que habla de la Tiranía de las Herramientas. Me parece que vale la pena invertir en mejorar el tablero, buscando  visualizar de forma simple los elementos claves del trabajo del equipo. Admiro por ejemplo el trabajo de Xavier Quesada Allue sobre Visual Management.

Seguro conocen esta versión básica del tablero de tareas de scrum (del libro Scrum and XP from the Trenches):

Si bien es una buena base para armar el primer tablero del equipo, he notado que a lo largo de los sprints, se suelen incorporar mejoras visuales en los tableros, propias de cada equipo, que resultan en nuevas áreas del tablero, hojas adicionales pegadas al lado, nuevos gráficos, trucos visuales para distinguir alguna información critica, etc. Estas extensiones al tablero, a veces se acercan al tuning de los autos, pero en muchos casos suelen dar información valiosa para la mejora continua y en mi opinión aportan a la construcción de identidad de un equipo ágil. En particular me provoca mucha satisfacción cuando quienes conforman un equipo pausan orgullosos con su tablero.

Seleccione 10 de las mejores extensiones que experimente en distintos equipos con tableros Scrum y Kanban. Gracias al equipo de Nora, a los Caesar girls and boy, al primer grupo QV y al team multi-aplicaciones TecP por compartir las fotos!

1. Tacho

Se agrega una hoja al costado del tablero, con un tacho de basura dibujado, donde ubicar ítems o tareas que fueron canceladas o suspendidas. 

Esta extensión aporta la posibilidad de visualizar fácilmente el nivel de "basura" en nuestro backlog y tareas.

2. Mini-Kanban

Se dispone de un espacio del tablero (muchas veces abajo) con un mini-kanban de tareas diversas que no suelen trabajarse de la misma forma que los ítems clásicos de un tablero Scrum, o que no siguen la misma secuencia de estados de los ítems principales de un tablero Kanban. Varias veces vi este espacio mini-kanban con 3 columnas (pendiente, en curso, terminado). Se suelen registrar tareas diversas como mejoras pequeñas, temas no planificados, inducciones sobre un tema, investigaciones, actualización de documentación general, etc. 

Es útil para registrar pequeñas tareas que se hacen además de los ítems planificados, y también para escoger algunas de estas tareas en pequeños momentos libres de la iteración. Si una de estas tareas lleva demasiado tiempo, suele ser mejor incluirla en los ítems principales del tablero luego de una priorización.  

3. Niko-Niko Calendar

En este caso se agrega una hoja donde dibujar las caras del niko-niko calendar (ver esta buena explicación del concepto) cada día.  

Me parece un muy buen indicador visual para darse cuenta del estado de ánimo del equipo en el tiempo. 

4. Sobre de Release

En la columna o lugar del tablero donde se ubican los ítems o tareas terminadas, se pega un sobre donde dejar los post-its de ítems o tareas correspondientes a un release dado. 

Está extensión permite tener un sobre con todo lo que se hizo para un release en particular, y simplifica la depuración del tablero. En tableros Kanban con un flujo continuo, es común que se vayan acumulando las tareas terminadas hasta que alguien las quiera depurar. 

Este mecanismo esta bueno para ordenar estas tareas por release. Eventualmente los sobres se pueden sacar del tablero después de un tiempo y archivar en algún lado. 

5. Lista de Impedimentos

En este caso se publica al lado del tablero una lista de los impedimentos más críticos detectados por el equipo (por ejemplo en las retrospectivas). Se puede priorizar y marcar el estatus de los impedimentos (por ejemplo tachar cuando se elimina el impedimento). 

Visualizar tan explícitamente los impedimentos del equipo suele tener un efecto interesante, ya que ayuda a responsabilizar a las personas involucradas para trabajar en resolverlos. También el hecho que lo puedan ver personas externas al equipo (por ejemplo una gerenta) a veces dispara reflexiones o acciones de resolución de los impedimentos fuera del equipo. 

6. Resumen de Retrospectivas

En complemento o reemplazo de la Lista de Impedimentos, se puede agregar al tablero una hoja (o varias) con el resumen de la última retrospectiva. En particular se pueden destacar las acciones de mejora elegidas y sus eventuales responsables. 

Exponer esta información aporta mucho a la transparencia, y también es un buen recordatorio de los compromisos asumidos durante las retrospectivas. 

7. Curva de Defectos

Se expone en un lugar del tablero una curva de los bugs/incidentes surgidos. Se puede refinar en incidentes Abiertos / Cerrados y/o hacer distinciones por el ambiente donde surgieron los incidentes (QA, Pre-Producción, Producción). Es interesante registrar los incidentes en el tiempo (por ejemplo por sprints o por semana), para poder detectar tendencias e identificar mejoras a realizar en consecuencia.

Esta extensión me gusta mucho porque permite agregar información visual sobre la calidad del desarrollo al tablero, que muchas veces está enfocado a aspectos de planificación y seguimiento. En particular nos da una buena idea de la deuda técnica de las aplicaciones desarrolladas, o de su nivel de estabilidad. Es un elemento visual bastante expresivo para disparar reflexión sobre la calidad de nuestros desarrollos y pensar en mejoras técnicas para prevenir incidentes.  

8. Asignación con Mini-Fotos

Esta extensión permite informar visualmente del responsable de una tarea en el tablero. Muchas veces se usan las iniciales de la persona en algún espacio del post-it correspondiente. Personalmente me gusta mucho imprimir pequeñas fotos de quienes conforman el equipo (por ejemplo de 2 cm x 2 cm), que luego se pegan al post-it correspondiente (con pinche si usan un tablero de corcho o cinta). 

Es la forma visual más clara para representar la asignación de una tarea a una persona. Si bien a veces se usan avatares elegidos por las personas, a mi gusto la mini-foto es la forma más transparente y clara que vi. 

9. Escala de Estimaciones

En equipos ágiles es moneda corriente usar estimaciones relativas con los ítems a desarrollar (features, user stories, etc.). Por ejemplo se estima que el ítem A es aproximadamente 2 veces más complejo de desarrollar que el ítem B. En esta extensión, se busca referencia explícitamente a ítems de iteraciones anteriores para las estimaciones relativas. Por ejemplo en un equipo usábamos kilogramos como unidad abstracta de complejidad para estimar user stories (un ítem de 10 kg es aproximadamente 5 veces más complejo de desarrollar que uno de 2 kg). Al final de cada sprint se revisaba cada "peso" de los ítems terminados para ver si estaba bien estimado, si el valor de kg necesitaba algún ajuste y finalmente si su "peso" ajustado era representativo para poder ser utilizado como referencia en estimaciones posteriores. Con todos los ítems representativos se fue armando al lado del tablero una escala de referencia para estimaciones relativas. 

He visto que tener una escala de referencia visible para estimaciones relativas a lo largo de los sprints es un mecanismo que permite acelerar la maduración del equipo en sus estimaciones. Lo bueno es que se puede ir construyendo de a poco, agregando ítems representativos a lo largo de los sprints. 

10. Cumulative Flow Diagram

En esta extensión se agrega al tradicional diagrama de burn-down del tablero un diagrama CFD (Cumulative Flow Diagram), que permite ver en el tiempo la evolución de los ítems trabajados por el equipo según su estado. En un equipo, en lugar de registrar la cantidad de ítems por estado, registrábamos la suma de complejidades de desarrollo de los ítems por estado, en este caso expresados en kilogramos. 

Es un buen elemento visual para detectar cuellos de botella, o empezar a introducir el concepto de limite de WIP en un equipo usando Scrum.

Espero que algunas de estas extensiones te den ideas para extender tableros y mejorar siempre la comunicación visual asociada...

Y en tu equipo, usan algunas de estas extensiones o tienen otras extensiones para compartir?

Lanzamiento de la Comunidad Ágil de Neuquen, Argentina

¡Atención!

Se lanza la Comunidad Ágil de Neuquen, Argentina! 


Buscamos fomentar el conocimiento y la aplicación de las practicas ágiles (Scrum, Extreme Programming, Kanban, etc.) en la zona del Alto Valle. 

La idea seria empezar con reuniones mensuales abiertas a todos los interesados. Será en algún lugar de Neuquen a definir en un horario a definir. La primera reunión la haremos durante la ultima semana de febrero. 

Si estas interesado, ¡registrate acá!

Se agradece la difusión.

¿Cómo hacer retrospectivas con equipos distribuidos?

No hay caso: siempre es mejor la retrospectiva cara a cara, donde todo el equipo está presente en el mismo lugar. Permite ampliar fuertemente y hacer más fluida la comunicación entre todos, el contacto visual, la lectura de expresiones corporales, etc.

Sin embargo, a veces la situación no es ideal, el equipo está distribuido y no siempre se puede reunirlo físicamente. En estos casos, aconsejo lo siguiente:

1. Tratar de todas las formas posibles de reunir el equipo físicamente para la retrospectiva. 
2. Si no se puede, hacer una retrospectiva distribuida. Me parece una lástima no usar esta herramienta fantástica que es la retrospectiva por el pretexto de la distancia geográfica. Obviamente no va a ser igual, quizás la calidad de la retrospectiva no sea la misma, pero aún así me parece que vale la pena hacer la actividad.

Dicho esto, quiero compartir algunos tips que pude valorar en retrospectivas distribuidas:

• Sobre el Espacio Compartido

Con equipos distribuidos, a veces la tentación es fuerte de no hacer una retrospectiva, aunque sea virtual. Y en algunas ocasiones se prefiere pedir a los miembros del equipo para que hagan su retrospectiva personal y manden sus conclusiones por email. Eso es lo peor que se puede hacer!

En equipos distribuidos me parece crítico tratar por todos los medios posibles de aumentar y cuidar las instancias de comunicación para limitar el déficit comunicacional generado por la distancia. Para las retrospectivas en particular es fundamental establecer un espacio (virtual) en un tiempo compartido por todos.

Con lo cual, mis recomendaciones para garantizar el espacio compartido son:

1. Convocar la reunión con anticipación, teniendo en cuenta las particularidades de cada locación involucrada (por ejemplo en una locación terminan de trabajar a las 17h, en otra tienen 2h de almuerzo, etc.).
2. Garantizar la presencia de todos en el horario acordado, con los medios y las herramientas correspondientes.
3. En cada locación, velar por lograr buenas condiciones para la retrospectiva (por ejemplo que el ambiente no sea muy ruidoso, que se pueda hablar sin molestar a nadie, etc.).
4. Durante la retrospectiva, si una persona se va, es importante que lo notifique explícitamente a todo el equipo, ya que no hay otra forma de darse cuenta. De la misma forma es importante que el facilitador avise explícitamente cuando inicia la retrospectiva, cuando termina, y eventualmente cuando se hacen pausas.

• Sobre la Comunicación Verbal

Al no estar físicamente juntos, el soporte a la comunicación durante una retrospectiva es crítico, y hay que tomarlo como tal. 

Para comunicación verbal, se puede usar el teléfono, skype, gtalk o alguna otra opción equivalente. Es importante probar previamente el medio elegido, para asegurar que se escuche bien a todos, que no haya cortes, etc.

Mis recomendaciones para garantizar la comunicación verbal son:

1. Elegir el mejor soporte a la comunicación verbal disponible. Eventualmente tener un Plan B por si se cae la comunicación en el medio de la retrospectiva.
2. Garantizar la disponibilidad de uso de los dispositivos (por ejemplo que haya micrófonos y auriculares disponibles, o teléfono con alto-parlantes, etc.).
3. Probar entre todos el soporte previo a la reunión para asegurar su buen funcionamiento. 
4. Durante la retrospectiva, es importante que el facilitador haga periódicamente chequeos para asegurar que todo el mundo sigue escuchando bien y pueda hablar sin problema. 

• Sobre la Comunicación Visual

Ver a los miembros del equipo que no están presentes en el mismo lugar es una fuente de información muy importante. En las retrospectivas, donde muchas veces afloran las emociones, la información visual y corporal aporta mucho contexto, y es uno de los aspectos más difíciles de garantizar en retrospectivas distribuidas. Además –y sobre todo si la reunión se extiende más de 1h- es mucho menos cansador poder ver a los interlocutores para mantener la atención y concentración en la reunión.

Conviene llevar al extremo todos los medios disponibles para tratar de compensar la distancia física. En particular los check-in / check-out de las retrospectivas son actividades que hay que cuidar mucho con equipos distribuidos (ver por ejemplo esta explicación de check-in/check-out por Ingrid Astiz). Es el momento donde todo el equipo escucha a los miembros uno a uno. Contar con vídeo para ver la cara y/o el cuerpo de la persona que habla durante el check-in y check-out aporta un contexto visual muy útil para la retrospectiva.

Mis recomendaciones sobre la Comunicación Visual son:

1. Si se puede contar con una instalación para hacer video-conferencias, usarla. Lo mejor es poder compartir una pantalla para trabajar y otra para ver la gente participando.
2. En caso de no contar con tal instalación, recomiendo usar Skype o Google+ Hangouts con webcams, o algo similar.
3. En la eventual ronda de check-in y check-out de la retrospectiva, recomiendo usar el video. En particular resulta muy útil enfocar la cara y/o el cuerpo de la persona que habla en estos momentos. 
4. Como siempre, garantizar los medios (webcams, etc.) para la vídeo y probar previamente que todo funciona bien.

• Sobre el Soporte Colaborativo

A mi gusto trabajar con post-its, marcadores y rota-folios en las retrospectivas presenciales es fantástico e incrementa notablemente la colaboración. En las retrospectivas distribuidas es otro aspecto complicado de implementar.

Sin embargo existen algunas herramientas para ayudarnos con eso. Personalmente he hecho retrospectivas distribuidas con planillas colaborativa en google docs y pizarra colaborativa de post-its en Edistorm.

Si bien todavía tiene algunas funcionalidades a mejorar, recomiendo muchísimo Edistorm. Es una herramienta estupenda que fue para mí un gran habilitador para hacer retrospectivas distribuidas. Básicamente Edistorm permite escribir post-its y compartirlos en un pizarra colaborativa en tiempo-real. Además tiene un mecanismo básico para poder votar sobre los post-its compartidos. En la captura siguiente podemos ver parte del resultado de una retrospectiva distribuida. En azul uno de los problemas tratados colaborativamente,  en verde las acciones de mejora elegidas y en amarillo otras acciones de mejora que no fueron elegidas.

Mis recomendaciones sobre el Soporte Colaborativo:

1. Elegir herramientas que permiten la colaboración en tiempo real, o sea que cada uno pueda ver en el momento lo que está editando el otro. 
2. Contar con un proyector en cada locación o con una notebook/PC para cada participantes (o eventualmente cada 2 participantes), para que todos puedan seguir en tiempo real lo que pasa en la herramienta.
3. Buscar herramienta que traten de re-crear el trabajo con post-its, como por ejemplo Edistorm. Identifiqué otras herramientas similares que no llegue a probar todavía en retrospectivas:  Twiddla, CardMeeting, Cacoo, BubbleUs, LinoIt, Corkboard
4. Preparar antes lo necesario (por ejemplo crear y compartir el soporte entre todos, crear usuarios/claves, armar la estructura de post-its necesaria en la herramienta, etc.).
5. Que el facilitador de la retrospectiva explique el uso de la herramienta a todos, para que no sea una traba a la hora de usarla. Elegir herramientas de uso simple. 

• Sobre el Cierre de la Retrospectiva

En las retrospectivas se recomienda terminar la reunión con un momento de feedback donde cada uno cuenta como percibió la reunión y/o como se sintió. Sin embargo, para las reuniones distribuidas, debido a la limitación comunicacional, suele ser difícil captar lo que siente cada participante si no se expresa explicitamente. Por ejemplo a veces no se puede notar a la distancia la cara de enojo de un participante. En retrospectivas es clave encontrar formas alternativas de expresión de este feedback. 

Por otro lado, las interferencias comunicacionales en las retrospectivas distribuidas son comunes (por ejemplo se escucha mal, hay ruido de fondo, se corta la comunicación, no se sabe quien habla, etc.). Para poder  sacar provecho igual, suele ser útil manejar cierta redundancia en las conclusiones de la reunión o en la información critica expresada.

Mis recomendaciones sobre el Cierre:

1. Hacer un ejercicio especifico de check-out o bien pedir feedback sobre la retrospectiva a cada uno. Es importante tomarse el tiempo necesario para que cada uno a su tiempo pueda expresarse y ser escuchado sobre el tema. En particular pedir feedback sobre como impacto el hecho de estar distribuidos.
2. Mandar a todos los participantes luego de la retrospectiva un resumen escrito de los resultados importantes de la retrospectiva (eventualmente quedan documentados en la herramienta elegida).

Dos reflexiones para cerrar (ya escribí mucho):

Para mí el agilismo implica un aprendizaje continuo, y por eso recomiendo ser tolerante con la retrospectiva actual y exigente con la próxima, en particular cuando se trata de equipos distribuidos. De esta forma podremos equivocarnos, aprender y descubrir entre todos mejores formas de hacer retrospectivas distribuidas. De a un paso a la vez...

Veo la retrospectiva como la herramienta más eficiente de consolidación de equipo (a veces se habla de team building, pero personalmente prefiero el termino de "Team Jelly", que vi en el gran libro Peopleware). En el caso de equipo distribuido, las posibilidades de hacer actividades que aportan a la consolidación de equipo son más limitadas que en equipos locales, con lo cual creo que hay que dar una importancia especial a las retrospectivas distribuidas. 

Dinámica de Retrospectiva: 3 caras y 4 capas

Me pareció muy buena esta dinámica de retrospectiva propuesta por Pablo Tortorella, que combina los conceptos de las 4 Capas de Raúl Uribe con la conocida técnica de retrospectiva Sad/Mad/Glad.

• Nombre: 3 caras y 4 capas
• Participantes: 5 a 12 personas
• Duración: 25 a 40 minutos
• Alcance: al finalizar una iteración corta (4 semanas o menos)
• Propósito: recabar información e indagar
• Facilitación: necesaria
• Objetivos: Esta dinámica grupal permite identificar aspectos positivos o negativos de una iteración y clasificarlos con una taxonomía integral.
• Material y Preparación: post-its, un  tablero o pared donde se puedan pegar los post-is, marcadores para cada participante. Se necesita únicamente preparar el tablero, pegando los post-its de columnas (Caritas) y lineas (Capas), como en el diagrama siguiente: 

• Pasos:
1. Quien facilita explica el objetivo de la actividad. En particular es importante explicar las 4 capas y dar ejemplos que permitan a quienes participan hacer la diferencia entre cada una de estas capas. Ver por ejemplo esta explicación de Ingrid Astiz, o este vídeo. Para explicar los conceptos de Mad/Sad/Glad, se puede usar esta definición. 
2. Cada persona participante escribe en post-its algunos aspectos de la iteración que la dejaron frustrada o enojada (Mad), aspectos que la pusieron triste (Sad) y aspectos que la pusieron feliz (Glad). 
3. Luego, las personas participantes presentan una a una uno de sus post-its, y en conjunto con el grupo identifica en que línea se tiene que ubicar, según si tiene que ver con Técnicas, Metodología, Filosofía o Ecosistema. Eventualmente se puede dividir el post-it en varios si abarca aspectos de varias capas. Si otra persona participante tiene un post-it muy similar, lo presenta y se pegan los dos post-its juntos. 
4. Una vez pegados todos los post-its, quien facilita ayuda al grupo a revisarlos para discubrir post-its que se puedan unir, algunos que haya que dividir, identificar algunos patrones o relacionar post-its de una misma temática. 

En esta foto se utiliza una variante mezclando Mad/Sad/Glad con Keep/Fix/Try.

• Variantes:
• En lugar de las caras Sad / Mad / Glad, se puede utilizar los conceptos de Start Doing / Keep Doing / More Of / Less Of /Stop Doing de la técnica de retrospectiva Estrella de Mar.
• Se pueden usar distintos colores de post-its según la columna (por ejemplo rojo para mad, naranja para sad y verde para glad), o según la línea de la matriz.
• Se pueden usar un color de post-its para aspectos positivos (Glad) y otro color de post-its para aspectos negativos (sad/mad). De esta forma al final se puede destacar visualmente las capas donde hay más aspectos positivos y las donde hay más aspectos negativos.
• Hacer la actividad sin introducir las 4 capas (solo Mad/Sad/Glad). Una vez ubicados todos los post-its en estas columnas, introducir las 4 capas y revisar los post-its para ubicarlos en las capas correspondientes. 
• Tips:
• Es fundamental la explicación inicial de las 4 capas, para que cada participante pueda entender los conceptos y luego incorporarlos para el resto de las actividades. Puede ser muy útil dar varios ejemplos de cada capa. 
• En función de la cantidad de participantes, quien facilita puede imponer la cantidad de post-its por persona y columna. Por ejemplo si hay mucha participación, puede ser bueno que cada persona escriba solamente un post-it por columna. 
• Quien facilita debe estar atento a los post-its ambiguos ("no se documenta suficiente"), demasiado abarcativos ("no tenemos metodología"). Si surgen estos casos, puede ser útil que ayude a la persona a refinar la idea.
• Quien facilita debe ayudar al grupo a identificar/definir los problemas, y dejar para una actividad posterior las propuestas de mejora.
• Esta actividad es una buena base para luego trabajar la priorización de los temas más críticos y desarrollar acciones de mejora.
• Origen: Pablo Tortorella - Matriz de Retrospectiva

Espero que esta dinámica los inspire y aguardo sus comentarios, mejoras, ideas, etc.

Para aprender más sobre retrospectivas, te recomiendo el Taller de Retrospectivas Poderosas para Equipos, de Kleer: Powerful Retrospectives for Teams.

Open Training: un mecanismo de capacitación auto-gestionada

De Mayo a Septiembre 2011, pudimos rodar en mi empresa una iniciativa de Open Training a la cual participaron 16 personas.

Espíritu del Open Training
Diseñamos este mecanismo de auto-capacitación tomando como base los conceptos de Open Space, Open Space Training y Caddying, que suelen convivir muy bien con los valores ágiles. En particular tratamos de sostener las siguientes premisas a lo largo de toda la iniciativa:

• La participación es libre, espontánea y voluntaria.
• El trabajo es auto-gestionado.
• Los temas son propuestos y elegidos por los participantes, dentro de los intereses profesionales que se pueden desarrollar en la empresa.
• El único objetivo es el crecimiento del grupo.
• Es la primera iteración de la iniciativa, con lo cual se considera una prueba y hay que mejorar el mecanismo.

Organización
Tomando la auto-gestión como base, la organización del Open Training fue bastante sencilla, y solamente hizo falta organizar las reuniones siguientes para darle un marco:

1. Kick-Off
Iniciamos con una sesión de Kick-Off, donde se explicaron el concepto, la dinámica y el marco (tiempos y recursos disponibles) de la iniciativa. Luego con una dinámica Open Space, los participantes propusieron temas de interés. Finalmente se auto-formaron 3 grupos de estudio, eligiendo cada uno un tema de capacitación (eligieron Qlikview, MS EPM y Automatización de Pruebas).

2. Diagnostico y Objetivo

Dos semanas más tarde, juntamos los 3 grupos para que presenten la evaluación inicial de sus conocimientos en el tema correspondiente y el objetivo a lograr al final de la iniciativa. Para llegar a eso, cada grupo tuvo que reunirse, investigar sobre el tema de referencia para poder definir unos ejes de aprendizaje y una escala de evaluación para cada eje. Cada miembro del grupo auto-evaluó su conocimiento actual con esta escala. Luego cada grupo definió un objetivo grupal a lograr al final de la iniciativa. La figura siguiente muestra el ejemplo del grupo Qlikview, donde se ven los ejes de aprendizaje elegidos: Componentes, Scripts, Entorno, Teoría e Informes. 

Se ven en el gráfico la evaluación promedio del diagnostico inicial y el valor objetivo de los conocimientos del grupo. Para cada eje, los grupos definieron el significado de los valores 1 a 4. Por ejemplo, para el eje Componentes, definieron la escala siguiente: 

1. Sin conocimiento
2. Conocimiento de los componentes disponibles y de las opciones gráficas
3. Conocimiento básico de los componentes, manejo de las expresiones y dimensiones
4. Conocimiento intermedio de los componentes y manejo de los componentes añadidos

3. Checkpoint

Siete semanas más tarde, juntamos a todos los grupos otra vez para que presenten sus avances. Cada grupo estuvo contando brevemente que estuvieron haciendo desde la reunión anterior, los resultados que lograron en este plazo y una nueva evaluación del estado del conocimiento del grupo. En algunos casos los grupos decidieron ajustar su objetivo para adecuarlo en función del conocimiento adquirido. En la figura siguiente, se ve la evaluación del conocimiento en este checkpoint para el grupo Qlikview:

4. Cierre y Retrospectiva
Ocho semanas después, hicimos la reunión de cierre de la iniciativa, otra vez con todos los participantes. En esta oportunidad cada grupo contó las acciones realizadas desde el checkpoint, los resultados alcanzados y presento una última evaluación de los conocimientos adquiridos, comparándolos con los objetivos iniciales. La segunda parte de la reunión fue una retrospectiva de la iniciativa, donde se trabajo sobre lo positivo y negativo de las distintas partes de la iniciativa, lo que permitió identificar y priorizar en grupo mejoras para una segunda iteración.




Resultados y Lecciones Aprendidas

Los resultados fueron variados:

• Los grupos crecieron en su conocimiento de los temas correspondientes, en forma medible.
• Un grupo se auto-disolvió al perder el interés por el tema elegido.
• Dentro de cada grupo, algunas personas pudieron aprender más que otras.
• En un grupo, además del conocimiento adquirido, se generaron herramientas concretas para uso en proyectos.
• Los objetivos de aprendizaje de cada grupo fueron demasiado ambiciosos y no se pudieron cumplir del todo.
• La mayoría de los participantes disfrutaron de la iniciativa.

De la retrospectiva de esta primera experiencia, surgieron varias oportunidades de mejora. Las más votadas fueron:

• Mejorar el mecanismo de selección de temas para que cada participante pueda tener un tiempo de reflexión antes de elegir.
• Acortar los tiempos entre checkpoints. 

Finalmente, todos los participantes expresaron el deseo de repetir la experiencia del Open Training.