Dinámica - Juego de listones para la enseñar mejora continua

Hola a todos

Les comparto este juego que ayuda a enseñar mejora continua a los equipos.

Saludos Ágiles
Jorge Abad

---

Comenzando con un equipo Scrum: Actividades para activar un equipo el primer día, team canvas y otras técnicas

Hola a todos

Hoy quiero compartirles una agenda de trabajo que pueden emplear el primer día que comienzan con un equipo ya sea tu rol como facilitador, scrum master, gerente ágil o gerente de proyectos.

Primero: Conozcamos nuestros nombres y una comida que no nos gusta

• Tiempo máximo : 30 minutos (dependiendo de la cantidad de personas)

En esta parte hago una ronda con el equipo y lo comenzamos por la derecha contestando varias preguntas sencillas

• Nombre
• Rol o cargo
• comida que no nos gusta (he notado que genera mucha empatía este tema), pero se puede reemplazar por:
• Película de cine que más le gusto
• lugar bonito al que haya ido
• última película de cine
• un restaurante
• etc.

La segunda persona contesta este sencillo esquema y repite el de su compañero de la izquierda junto con la comida con le gusta, la tercera persona lo mismo con sus dos compañeros, hasta que el último (o sea el facilitador) dirá el nombre de todos y la comida que no le gusta.

Segundo: Una actividad de equipo

• Tiempo máximo : 60 minutos (dependiendo de la actividad)

Resulta que el equipo aun no es un ser como tal, saben todos que ese es el objetivo pero aun no nace, es un imaginario. entonces en este punto recomiendo realizar un reto de equipo, dentro de este reto de equipo los ponga a trabajar juntos y les de sinergia, dentro de estos retos pueden estar los siguientes:

• Para equipos medianos y grandes (6 a 20 personas)
• Ball Point Game - (clic aquí para ver las unas indicaciones)
• La dinámica de listones - (clic aquí para ver el video) (1)
• Para equipos pequeños (de 6 o menos personas)
• Construir una torre con un trozo de cinta, spaguettis, un metro de hilo y en la punta un masmellow - (clic aquí para ver el video) 

Tercero: Un nombre y una imagen

• Tiempo máximo : 30 minutos 

Habiendo interactuado juntos, la idea es que cada uno se dibuje dentro de un pliego de papel y busquen un nombre para el equipo, esta actividad les da identidad, pertenencia y los ubica en un mismo espacio.

Cuarto: Personal Maps o Mapas Personales

• Tiempo máximo : 45 minutos 

Luego cada uno de los integrantes del equipo debe realizar un mapa personal (o elaborarlo entrevistado por un compañero) y lo presenta el equipo, esta actividad ayuda a mejorar las interacciones y a entender que no somos roles, ni cargos, somos personas que tienen una vida, metas y aspectos muy variados fuera de la zona de interacción, y permite mejorar la forma como vamos a trabajar.

Para conocer más hacer clic aquí - Mapas Personales

Y para cerrar, Team Canvas (2)

• Tiempo máximo : 120 minutos

En esta actividad el equipo en conjunto define aspectos fundamentales de su interacción

• Propósito
• Personas y roles
• Objetivos comunes
• Valores
• Reglas y actividades
• Fortalezas
• Debilidades y riesgos

Van navegando por cada de uno de ellos con un timebox determinado, en este link encontrarán la guía para realizarlo - http://theteamcanvas.com/use/

Con esto definido, están listos para los retos que juntos van a enfrentar.

Concluyendo

Esta agenda es una propuesta inicial, pueden haber muchas agendas de trabajo, si tienen mejoras me encantaría que me las compartieran.

Saludos ágiles

Jorge Abad

Referencias, comentarios, aclaraciones y notas

1. Esta actividad la conocí gracias a mi estimado compañero y amigo Sebastián Velásquez - @sebasla
2. Este lienzo lo conocí gracias a mi amigo y maestro Lucho Salazar - @LuchoSalazarC

Comenzando con un equipo scrum: Personal Maps - Mapas Personales

Hola a todos

He notado en la vida que pequeñas acciones generan gran impacto, y hoy quiero compartirles algo que cumple estas características, que habilita la generación de equipo (1) entre quienes regularmente son compañeros de trabajo o integrantes de un grupo, esta sencilla herramienta son los Mapas Personales - o Personal Maps -(2), técnica en la cual empleamos un mapa mental para contar quienes somos (3). Este mapa mental se construye poniendo nuestro nombre en el centro y alrededor se complementa con diferentes aspectos que son detallados según se requiera, estos aspectos pueden ser.

• Educación
• Familia
• Trabajo
• Valores
• Objetivos - metas
• Hobbies
• Casa
• Amigos
• Tres momentos importantes de la vida (4)
• entre otros

Realizando este sencillo mapa todos sabrán mejor quienes somos y nos ayudará acortar la transición  entre ser compañeros de trabajo a un verdadero equipo.

Mapa Personal / Personal Map - Elaborado para el Taller de Energizando Equipos con Técnicas de Management 3.0 (5)

Sugiero que el Mapa Personal se elabore cuando estamos comenzando a crear un equipo de trabajo, y para su construcción sugiero dos técnicas:

1. Cada cual elabora su mapa y lo explica a sus compañeros
• Elaboración 10 minutos
• Explicación 20 minutos (suponiendo un equipo máximo de 10 personas, tal vez tome más o menos tiempo dependiendo de la cantidad de integrantes)
2. Otro elabora y explica mi mapa
• Las personas que van a conformar el nuevo equipo se dividen en parejas 
• cada pareja se entrevista mutuamente, elabora el mapa de su compañero (tiempo 10 minutos)
• Cada persona explica el mapa de su compañero a todo el equipo (tiempo aproximado 20 minutos)

Luego estos mapas se pegan en la pared para que estén disponibles para todos y de esa manera se ayuda a mejorar las interacciones pues comprendemos que detrás de cada uno hay una vida, un otro, y no solo un cargo o rol con el cual interactuar.

Bienvenido el feedback y los resultados de esta experiencia

Saludos ágiles

Jorge Abad

Notas, aclaraciones, comentarios y referencias

1. Esta técnica la conocí gracias a mi gran amigo Lucho Salazar - @LuchoSalazarC, agilista y apasionado por el Management 3.0 - lugar de donde viene esta técnica - .
2. Management 3.0 Practice: Personal Maps
3. Quienes somos es muy ambicioso, pero presenta algunos rasgos principales 
4. Sugerido por mi
5. Taller facilitado por Lucho Salazar y Mi persona (su servidor)

Taller: Kanban Avanzado. Superando el Limitar el WIP

Hola a todos Quisiera compartirles este taller de Kanban.

• Paso 1. Ver primero el video
• Paso 2. Continua leyendo
• Paso 3. Si lo deseas, puedes facilitar el taller con las diapositvas que se encuentran al final.

Objetivo

En este taller pasarás de ver Kanban como una estrategia de gestión visual y comprenderás el poder que puede darle a tu equipo en especial si trabajas con áreas de gestión de tickets, incidentes o flujo continuo, conocerás y gestionarás adecuadamente el flujo acumulativo y comprenderás como optimizar tu proceso.

Descripción

Este taller de Kanban busca no solo explicar en que consiste kanban, sino proporcionar a los asistentes con un ejemplo práctico relacionado con los tres principios (visualizar el proceso, limitar el wip y optimzar el flujo) adicionando elementos como flujo acumulativo y métricas sobre el proceso y como ir adaptando el proceso de acuerdo al flujo. El público objetivo son todos aquellos que quieran saber más de kanban, y quienes trabajan bajo esquemas de flujo continuo u equipos de soporte.

Tiempo requerido

• 2 horas

Insumos

• 70 medias hojas
• 70 posit
• Video Beam
• Texto Lorem ipsum
• Cronometro
• 10 lapiceros  o más
• Excel
• Hoja de cálculo para generar gráfica de flujo acumulativo: (Clic aquí para descargar) [soporta simulaciones de 4 y 5 pasos]
• 5 equipos de al menos 2 personas cada uno
• 1 facilitador que lidere el taller

Instrucciones los pasos del taller son los siguientes

• Se creará un tablero Kanban con 5 pasos (P1, P2, P3, P4, P5)

Tablero Kanban de 5 Pasos

Tablero Kanban de 4 Pasos (también soportado en este taller)

• Se formarán 5 equipos de trabajo
• A cada equipo se le asignará una parte del proceso que deberán gestionar en el kanban,
• Se crearán al menos 60 notas adhesivas (pósit)  aproximadamente  (o al menos 10 y de forma incremental se crearán hasta 60 cada iteración)  con la siguiente información (ver video minuto 1:49)
• Id del ticket
• P1 - y luego un número aleatorio del 4 al 12
• P2 - y luego un número aleatorio del 4 al 12
• P3 - y luego un número aleatorio del 4 al 12
• P4 - y luego un número aleatorio del 4 al 12
• P5 - y luego un número aleatorio del 4 al 12

• Los equipos deberán realizar escribir en media hoja un texto del lorem ipsum - http://es.lipsum.com/ de forma secuencial (ver video minuto 3:11) de la siguiente forma

• Equipo 1, (ver imagen pósit anterior ) P1-10 (escribirá en este caso 10 palabras del texto) "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec vehicula " luego mueve el posit a la siguiente paso y el 
• Equipo 2,  (ver imagen pósit anterior ) P2-6  (escribirá en este caso 6 palabras del texto, donde iba el anterior) "lacus pharetra sem mollis, ac hendrerit " luego mueve el posit a la siguiente paso y el 
• Equipo 3,  (ver imagen pósit anterior ) P3-7  (escribirá en este caso 7 palabras del texto, donde iba el anterior) "nunc faucibus. Pellentesque viverra nulla in erat  " luego mueve el posit a la siguiente paso y el 
• Equipo 4, (ver imagen pósit anterior ) P4-8  (escribirá en este caso 8 palabras del texto, donde iba el anterior) "elementum lobortis. Donec ut pharetra dolor. Vestibulum bibendum  " luego mueve el posit a la siguiente paso y el 
• Equipo 5,  (ver imagen pósit anterior ) P5-6  (escribirá en este caso 6 palabras del texto, donde iba el anterior) "tincidunt arcu nec vestibulum. Vivamus sapien  " luego mueve el posit a la siguiente al DONE.
• Esto se realizará por 3 minutos, que significarán un día de trabajo o iteración. durante ese tiempo los equipos moverán las tarjetas de un paso a otro y llenando los textos de lorem ipsum de las medias hojas segun se les indique en la nota adhesiva o posit. 
• Se sugiere que cada equipo tenga un representante ante el tablero kanban que se encargue de llevar trabajo al equipo y de mover las tarjetas o posit.
• Se realizarán 4 rondas grandes de 4 iteraciones de 3 minutos
• Al finalizar cada ronda se decidirá donde limitar el WIP (work in progress) y que mejoras realizar en el proceso
• El facilitador  tomará nota de cuantos ítemes hay en cada columna al final de cada iteración. (ver video minuto 4:39)
• Al finalizar las cuatro rondas los equipos se espera haber estabilizado el flujo de trabajo para todos los equipos y tener un kanban balanceado, sin cuellos de botella.
• El facilitador  presentará la gráfica de flujo acumulativo generada y los resultados obtenidos, de igual forma que otra información se puede obtener de un manejo numérico del kanban.

Data Generada en un Taller de Kanban Avanzado

Gráfica Generada de Flujo Acomulativo

Hoja de cálculo para generar gráfica de flujo acumulativo anterior: (Clic aquí para descargar)

Gráfica de Flujo Acumulativo de un Proyecto Real

Diapositivas para apoyar el taller

Taller: Kanban Avanzado. Superando el Limitar el WIP from Jorge Hernán Abad Londoño

Solo tres cosas para terminar

• Si quieres hacer este taller y necesitas más explicación no dudes en contactarme a través de mi twitter @jorge_abad
• Si haces el taller me gustaría compartieras la experiencia en este post o me dieras feedback de que hiciste y como podemos mejorarlo
• ¿Podrias trinar algo (tuitiar, o un lanzar un tweet)  con el Hastagh #TallerKanbanAvanzado sobre como te fué? sería un honor para mi.

Saludos ágiles Jorge Abad

Notas Aclaraciones 

1. Es correcto decis pósit - http://dle.rae.es/?id=TnfXVsj
2. Espero pronto estar compartiendo más de este taller
3. Este taller es de mi autoría, lo cree al observar que no podría transmitir en mis sesiones de entrenamiento mucho sobre kanban, en el proceso de formación del taller fueron útiles las guias, post, slides y ejemplos de
• Leonardo Agudero - @sweepnoise
• Thomas Wallet - @WalletThomas
• Aguistin Villena - @AgustinVillena
4. [Nuevo Sep 20-2016] He actualizado la hoja de cálculo para soportar 4 pasos.

Una dinámica para aprender escucha activa - escucha inactiva

Hola a todos

Hace poco me di cuenta (me hice consciente) de que estaba en una reunión pero que no estaba 100% presente, no estaba 100% en actitud de escucha activa, tenia un discurso interno en unos temas personales que no me dejaba:

• entender que estaba pasando
• entender lo que estaban hablando y como me estaba aportando
• poder aportar cuando sea necesario
• poder preguntar cuando no entendiera algo.

También me he dado cuenta que esto mismo sucede cuando en una reunión

• alguien lleva un computador (cosa que yo he hecho, mea culpa) para hacer otra cosa (contestar correos, o chatear con alguien de la oficina) o  mientras los otros hacen definiciones o se toman decisiones, la persona del computador solo asiente (mueve su cabeza) y sigue en lo suyo.
• pasara como si algo que escucho "le pareciera","le sonara" pero no pudo absorberlo y aportar
• Lo mismo sucede con quienes usan su celular durante la reunión  (cosa que yo he hecho, mea culpa) para responder un whatsapp, revisar facebook o distraerse y llega al punto que estan completamente aislados y lo único que hacen es asentir, o cambiar la cara, sonriendo o poniéndose serios según lo que leen, pero realmente no esta conectados.

Dado este escenario me dí a la tarea de crear una sencilla dinámica para ilustrarle a los equipos lo ineficiente que es este tipo de multitasking, lo que es la escucha activa y la escucha inactiva, a que impacto tiene en el entendimiento de nuestro entorno, Es simple:

• Insumos
• Tres participantes
• Uno que será EL FACILITADOR
• otro será EL NARRADOR quien contará algo
• otro será EL MATEMÁTICO que trate de hacer multitasking o escucha inactiva
• Un cronometro
• Actividad
• El Facilitador tendrá el cronómetro vigilando que no se superen los dos minutos
• El Narrador durante dos minutos contará al detalle exhaustivo algo de su vida diaria ejemplo: ir al trabajo, regresar a la casa, lo que hace un domingo normal
• El Matemático estará realizando mentalmente los múltiplos de 7, ej: 7, 14, 21, 28, incrementalmente hasta que terminen los 2 minutos, y pero tratará de poner atención a la historia del Narrador pues luego este le realizará preguntas sobre su narración
• El Facilitador estará tocando el hombro del Matemático para que diga en voz alta en que multiplo va
• Al finalizar los dos minutos, el narrador hará preguntas sobre detalles de su narración al matemático validando que haya entendido la narración y detectando que tanto comprendió.
• Luego entre los tres participantes concluyen acerca de la actividad

Variaciones

• Variación 1: Matemáticamente más dificil
• El facilitador le puede decir al matemático que sume algún numero de un dígito a la serie, ejemplo, va en 63 y se le pide que sume 5, entonces seguirá en 68, 75, 82 etc
• Variación 2: Practicando escucha activa
• Repetir la sesión de 2 minutos pero esta vez el matemático hará preguntas, y parafraseará al narrador para entender lo que dice 
• Luego el Matemático repite la narración y el narrador la califica
• Variación 3: El matemático narrador
• Se le pide al matemático que realice la narración y el narrador la califica
• Variación 4: De matemático a revisor de facebook, whatssapp y correo
• En vez de realizar las multiplicaciones se le pide al Matemático que revise honestamente  su smartphone ya sea facebook, whatsapp o su correo mientras el otro habla.

Estas variaciones pueden usarse según desee el facilitador.

Hasta acá la dinámica, recomiendo ver este video para aprender más de la escucha activa http://www.lecciones-aprendidas.info/2016/04/saber-escuchar-escucha-activa.html

Bienvenido el feedback y compartir las experiencias empleándola.



Saludos ágiles
Jorge Abad

Una actividad/juego de sensibilización sobre los resultados de la ejecución tradicional (cascada o RUP) en proyectos de software

El JUEGO DE LA MUESTRA ESTADÍSTICA

Hola a todos

Muchas veces antes de dictar un entrenamiento o una charla sobre metodologías ágiles realizo la siguiente actividad  (la aprendí de mi colega Leonardo Agudelo - https://twitter.com/sweepnoise )

1. Trazo una linea divisoria imaginaria, o con cita de enmascarar 
2. Pongo a todo el grupo a un lado de la línea
3. Comienzo a realizar las siguientes preguntas e invito a los que las van cumpliendo pasen al otro lado de la línea
4. y así voy avanzando hasta que veo que es suficiente

La fuerza de la actividad radica en las preguntas y en que todos perciban lo mal o bien que les esta yendo haciendo la ejecución actual de proyectos (adicionalmente que no son los únicos que padecen los problemas de su día a día)

Estas son algunas de las que uso:

Nota: Resaltaré las preguntas que más me han sorprendido.

----

• Categoría: Roles
• Objetivo: Saber con quienes comparto la charla o entrenamiento
• Preguntas
• ¿quiénes son gerentes de proyecto?
• ¿quiénes son comerciales?
• ¿quiénes son desarrolladores?
• ¿quiénes son testers?
• etc

--

• Categoría: Tiempo
• Objetivo: Sensibilizar que la ejecución tradicional (cascada, Rup, o cualquier variación) no es precisa en cuanto al tiempo 
• Preguntas
• ¿quiénes han estado en un proyecto que se ha demorado el cuadruple de lo planeado?
• ¿quienes el triple?
• ¿quienes el doble? 
• ¿quienes han trabajado en un proyecto seguido sábados y domingos incansablemente por más de un año? -(lamentablemente los hay)
• ¿8 meses?
• ¿6 meses?
• ¿4 meses?
• ¿2 meses?
• ¿1 mes?

--

• Categoría: Costo
• Objetivo: Sensibilizar que la ejecución tradicional los costos no son predecibles
• Preguntas
• ¿quiénes han estado en un proyecto que ha costado el cuadruple de lo planeado?
• ¿quienes el triple?
• ¿quienes el doble? 

--

• Categoría: Alcance / Requisitos 
• Objetivo: mostrar que las especificaciones firmadas no son garantía éxito.
• Preguntas
• ¿quienes han estado en un proyecto donde a pesar de haber construido lo que hay en las especificaciones, el cliente afirma "ok, es lo de las especificaciones pero eso no es lo que yo quería"?
• ¿Quienes han estado en un proyecto donde los controles de cambio cuestan mas que el proyecto original?
• ¿a quienes el cliente les ha dicho?
• ¿yo se que yo firmé eso, pero eso no es lo que yo necesito?
• ¿es que esa funcionalidad aun no esta clara y no se como va funcionar?

--

• Categoría: Éxito de los proyectos tradicionales
• Objetivo: Sennsibilizar sobre lo dificil que es ser éxitoso en tiempo, costo, alcance y calidad en un proyecto tradicional
• Preguntas
• ¿quiénes han estado en un proyecto exitoso en tiempo, costo, alcance y calidad? (se sorprenderán.. muy pocos) 

--

• Categoría: Estimaciones
• Objetivo: Mostrar que tan acertadas son las estimaciones en proyectos de software son imprecisas, debido a la incertidumbre.
• Preguntas
• ¿quienes se han equivocado en una estimación el 8 veces, ejemplo dijeron 1 día y se demoraron 8?  -(lamentablemente los hay)
• ¿6 veces?
• ¿4 veces?
• ¿2 veces?

(será que no sabemos en que estamos trabajando)

--

• Categoría: Desgaste del equipo y de la vida personal
• Objetivo: Mostrar la forma en que hemos desgastado nuestras vidas y la de los equipos de trabajo forzando el éxito a toda costa
• Preguntas
• ¿a quienes su familia, novio, novia, esposo, esposa, hijos, hermanos madre, les ha dado un ultimatum...¡o renuncias o no vuelves a saber de nosotros! (aca el resultado ha sido doloroso, algunos comparten que les ha costado el divorcio, o situaciones similares)
• ¿quienes han trabajando seguido mas de ?
• 36 horas
• 24 horas
• 16 horas

--

• Categoría: los riesgos
• Objetivo: Evidenciar los riesgosos que son los proyectos de desarrollo de software
• Preguntas
• ¿ a quienes se les ha dañado una entrega teniéndola completamente lista?

--

• Categoría: Desperdicio /se construye lo que no se usa
• Objetivo: Mostrar cuanto software es desperdicio (la estadística muestra que del 100%, solo el 50% es usado, de ese 50%, el 20% con frecuencia y el 30 rara vez - Chaos Manifesto 2013)
• ¿quienes consideran que el 100% del software que hacen es usado por el cliente?
• ¿el 90?
• ¿el 80?
• ¿el 70?
• ¿el 60?
• ¿el 50?
• ¿quienes consideran que construyen documentación que nunca será usada?
• ¿quienes han estado en un proyecto que no salió a producción?
• ¿quienes han estado en un proyecto que saló a producción pero nadie usa?
• ¿quienes han estado en un proyecto donde dicen, la documentación que se hizo no sirve, volvamosla a construir?

y así.. sucesivamente

Si tienen más preguntas para la actividad, que bueno sería las compartieran...

Como se pueden dar cuenta no son los únicos que viven estos males.

Hagan la actividad y compartan la experiencia en este post, se llevarán sorpresas muy interesantes.

Saludos ágiles

Jorge Abad

Mi evolución sobre las retrospectivas en Scrum

Desde hace un tiempo he venido actualizándome sobre las retrospectivas en Scrum (la verdad no he leído y estudiado todo lo que he querido) pero he realizado varias con mi equipo, y he particpado en otras como coach de la organización en la que estoy.

Al inicio, comencé con el típico (propuesto en http://www.mountaingoatsoftware.com en su introducción a Scrum):

• Qué hicimos bien
• Qué hicimos mal
• Y qué debemos mejorar

Pero note que nos estábamos quedando quietos, las tres preguntas anteriores solo son un diagnóstico y te proporcionan una foto de como te fue el el Sprint que acabas de terminar pero no te lleva a la acción.

Luego entonces decidi madurarla un poco y agregar

• Qué se debe mantener
• Cómo hacerlo mejor

(esta versión es mas coherente con un ciclo de mejora PHVA de mejora continua)

Pensando en:

•  una retroalimentación al proceso 
• y una mejora del mismo, 
• manteniendo aquello que nos había generado valor.

Luego, al leer a Alan Cyment me animé a cambiar las preguntas, adicionando los aspectos de Productividad, Calidad y Felicidad, generando una matriz que involucraba los aspectos anteriores

Que como pueden deducir me llevaba de nuevo a un diagnóstico pero me permitía ver aspectos interesantes del equipo.

Luego la maduré a la versión que utilizo actualmente, que presento a continuación: 

(esta actividad toma aproximadamente 40 a 50 minuntos)

Aclaro, que sigo visionando en la parte superior los aspectos de productividad, calidad y en especial felicidad para comprender como mis equipos quieren cambiar y mejorar, y en especial ser más felices, para estar acordes con el principio del manifiesto "Los proyectos se desarrollan en torno a individuos motivados..." Y si mi equipo esta motivado y feliz pues al proyecto, y a todos nos irá mejor y será más fácil y natural la mejora.

Pronto intentaré otras técnicas:

• Dinámica de Retrospectiva: 3 caras y 4 capas (mad/glad/sad/  vs Filosofía, metodología, técnicas y ecosistema - http://thomaswallet.blogspot.com/2011/12/dinamica-de-retrospectiva-3-caras-y-4.html#.UXYWoqLEK3H
• Mad/Sad/Glad vs Keep/Fix/Try
• Estrella de mar - star fish - http://www.proyectosagiles.org/retrospectiva-estrella-mar-starfish-retrospective-scrum
• Start doing: comenzar a hacer
• More of: mas de lo anterior
• Keep doing - Seguir haciendo /mantener
• Less of: menos de
• Stop doing: dejar de hacer

Y les contaré como me fue.

Seguiremos avanzando en este aspecto de las retrospectivas, pero lo que si tengo claro es:

• De una retrospectiva se debe avanzar del diagnóstico (del qué) a la acción (al cómo vamos a mejorar).
• El equipo guiado por el Scrum Master debe mirar como avanzar y mejorar su proceso
• Las mejoras identificadas deben ser igualmente priorizadas e identificadas a realzar al corto, mediano y largo plazo. (muchas veces no podemos mejorar todo de una vez, sino orgánicamente de la misma hacemos con el producto) .

Hasta la próxima.

Quedo atento a sus comentarios, observaciones, mejoras y/o sugerencias.

Una dinámica/juego para enseñar Scrum - Revista Scrum

El pasado 20 de marzo de 2013 en la materia Gestión de Proyectos Informáticos la cual imparto para lacohorte 9 de laEspecialización y Maestría en Ingeniería de Software en la Universidad de Medellín (Medellín - Antioquia - Colombia) www.udem.edu.co ,  realizamos una simulación para aprender como funciona de Scrum.

Antes del Juego se realizó la presentación  SCRUM (ver diapositivas) en la cual se revisaron los conceptos principales y más importantes del marco de trabajo (framework) de SCRUM.


Los parámetros fueron los siguientes:

3 equipos de 6 personas, cada equipo provisto al menos de:

• Un Scrum Master (elegido por el equipo)
• Un Product Owner (elegido por el equipo)
• 3 Revistas de variedades
• 3 Tijeras
• Pegante
• 40 Hojas reciclables tamaño carta
• 2 tacos (bloques) de Pos-it/Sticky Notes/
• Lapiceros y marcadores

Objetivo:

• Construir una revista basada en recorte de imágenes y textos que estos sean pegados en las hojas reciclables tamaño carta. 

Requisitos:

• La revista debe contar con un índice de artículos y numeración para cada hoja.
• Todo a excepción del indice de artículos debe ser cortado y pegado

Para construir las hojas se emplearán fotos de diferente tipo y renglones de texto cortados en forma de rectángulo. Se emplearán los siguientes tipos de fotos

• A: Foto de una mujer
• B: Fotos de un carro
• C: Fotos de un hombre
• D: Foto de algo que sea diferente a A, B, C y D

 Las hojas de la revista pueden de las siguientes tipos:

• Hoja Tipo 1:  1 foto + 1 descripción
• Hoja Tipo 2:  2 fotos + 2 descripciones
• Hoja Tipo 3:  3 fotos
• Hoja Tipo 4:  5 fotos + 1 descripciones
• Hoja Tipo 5:  Menú
• Hoja Tipo 6:  2 fotos
• Hoja Tipo 7:  3 fotos + 3 descripciones

Fotografía 1

Por lo tanto si se me pide una Hoja Tipo 7 con fotos A, significa que la hoja debe contener:

• 3 fotos de mujeres recortadas
• 3 descripciones de texto recortadas

DETALLES DEL EJERCICIO

1. Se crearon los tres equipos
2. Se explicó la forma de armar la revista
3. Se creó un Product Backlog priorizado para cada equipo (Ver imagen en las columnas PB1, PB2, PB3)
4. Se definió un Sprint de 41 minutos con las siguientes características de tiempo:

• Plannig = 8 minutos
• Duración del dia 1= 7 minutos
• Reunión de daily 1 = 2 minutos
• Duración del día 2 = 7 minutos
• Reunión de daily 2 = 2 minutos                                    
• Duración del día 3 = 7 minutos                                   Fotografía 2
• Review = 4 minutos
• Retrospectiva 4 minutos

Al final del ejercicio se realizaron 3 sprints, para un total de 123 minutos. (2 horas de trabajo)

5. Se realizó una calificación (al inicio del juego) por puntos para cada "HOJA TIPO" en donde por votación por EL JUEGO DEL POKER (puntuando con 1, 2, 3, 5, 8,13 - y empleando cada integrante la aplicación para Android Scrum Poker para simular las cartas) se puntuaron cada de las hojas asi:

• Hoja Tipo 1:  3 puntos
• Hoja Tipo 2:  8 puntos
• Hoja Tipo 3:  5 puntos
• Hoja Tipo 4:  13 puntos
• Hoja Tipo 5:  3 puntos
• Hoja Tipo 6:  3 puntos
• Hoja Tipo 7:  13 puntos

Fotografía 3

6. A cada Scrum Master se le enfatizó las características de su rol.
7. A cada Product Owner se le enfatizó las características de su rol y la potestad de recibir o rechazar las Hojas con sus diferentes fotografías y descripciones (que vendrían a ser el símil de las historias de usuario), adicionalmente de hacer respetar la prioridad del product backlog
8. Se estableció el criterio de DONE como: "una hoja con todos sus elementos correctamente pegados"
9. Se insistió que el objeto del planning era:

• establecer el compromiso de puntos
• realizar el tasking plasmando la hoja (u símil de Historia de Usuario) de la siguiente manera :

   HISTORIA TIPO 4 = Foto1 + Foto2 + Foto3 + Foto4 + Descripción1 

(ver la Fotografía 1)

• Construir el Kanban de acuerdo al tasking y  poniendo en la parte superior la historia de mayor prioridad.
• Construir el Burndown chart

10. Se insistió que NO era un ejercicio donde se COMPETÍA por construir la mayor cantidad de Backlog, sino que tenía como objeto REALIZAR CORRECTAMENTE Y PASO A PASO LO FORMULADO POR EL FRAMEWORK DE SCRUM.

12. Se empoderó al equipo para que alguien dentro del mismo se encargara de actualizar la gráfica de BURNDOWN CHART con los puntos pendientes al final de cada día.

13. [esto se olvido, aunque se debió haber hecho] En el uso de Kanban se debe recordar quien va y toma una tarea del kanban (va y "merca" decimos donde trabajo) para ejecutarla debe firmala y pasarla WIP y luego a DONE cuando la termine.

Fotografía 4

Fotografía 5

Fotografía 6

RESULTADO FINAL DEL EJERCICIO

1. Se realizaron 3 Sprints para construir el Backlog.
2. Los equipos lograron con las retrospectivas corregir el proceso y ser más eficientes construyendo páginas y de esta manera aumentaban el compromiso durante los dos planes subsiguientes.
3. Durante el ejercicio se corrigieron aspectos como:

• la necesidad de hacer el daily de pie
• la actualización día a día del Burndown chart
• la actualización y paso de tareas en el kanban
• en el kanban en la columna del WIP (work in progress) solo puede existir una tarea por miembro del equipo.

4. Se hizo una retrospectiva del ejercicio por parte de los estudiantes diciendo que la compresión del framework aumento de forma considerable con el ejercicio.

-----

Este fué el ejercicio que se realizó, pienso seguir empleándolo en las capacitaciones que dicto y en los cursos que imparto.

Queda así a disposición de la comunidad ágil y si tienen retroalimentación será bienvenida.

Saludos

Jorge Abad