Agility at work: Actividad: Lo básico de Kanban y Scrum construyendo una Lego City

En este post compartiré con vosotros mi experiencia en la enseñanza de los conceptos básicos de Kanban y Scrum a través de una entretenida actividad de trabajo en equipo para construir una Lego City. Esta actividad la he venido refinando en su aplicación en mis clases con alumnos de Ingeniería Informática y también en talleres dirigidos a empresas.

El objetivo de esta actividad es doble, por un lado se consigue ilustrar los conceptos básicos de Scrum y Kanban y la dinámica de trabajo en equipo asociada, y por otro, sirve para romper el hielo en equipos donde los integrantes acaban de conocerse o que no estaban acostumbrados a trabajar en un contexto de agilismo.

Tal como en la mayoría de las simulaciones de Scrum con Lego que se pueden encontrar en internet, las primeras ocasiones cuando realicé esta actividad me esforcé por incluir muchas situaciones de gestión en el Kanban puesto que quería introducir al mismo tiempo todos los conceptos de Scrum. Con la experiencia la he ido simplificando hasta llegar a su estado actual, en el cual el propósito es menos ambicioso en cuanto a conceptos de Scrum pero más efectivo en cuanto a iniciar la dinámica de trabajo del equipo. Además, para ilustrar aspectos específicos de Scrum tengo otra actividad que realizo posteriormente y la cual queda perfectamente acoplada a esta primera actividad. Esta otra actividad la denomino Scrum + Kanban con un equipo self-organizing y cross-functional.

Espero que esta información os sea de utilidad. No dudéis en contactarme para dudas o sugerencias!!

Preliminares

La actividad tal como os la planteo os ocupará una hora y media. Debéis elegir un espacio apropiado, comenzando con una mesa o agrupación de mesas que ofrezcan un espacio amplio para trabajar, que tenga la posibilidad de montar el panel Kanban en una superficie junto a las mesas de trabajo.

Las construcciones Lego tienen diferentes niveles de dificultad y correspondientes tiempos de ensamblado. Es importante que según esto los componentes estén semi-ensamblados, de lo contrario será muy frustrante para los participante no terminarlos en el tiempo establecido (esto de todas formas ocurrirá, pero crea demasiado ruido que suceda masivamente). En el caso de Legos que puedan tener una descomposición natural, tenerlos ya separados, por ejemplo, un restaurante de tres plantas, tener separadas las piezas de cada planta (estos casos se sugerirán como desarrollo incrementan en diferentes sprints), otros casos como componentes múltiples, por ejemplo Banco + Camión Blindado + Coche de Policía, es conveniente que sus piezas estén separadas. Por otra parte, se sugiere tener bloques, ventanas y puertas independientes para las Historias de Usuario que impliquen crear elementos no predefinidos. Finalmente, otro ingrediente interesante es dejar disponibles las instrucciones de montaje (que tienen su analogía con especificaciones precisas de desarrollo), además, en algunos de los contenedores de las piezas dejar un recorte de la caja de Lego correspondiente que da una visión del resultado esperado (en algunos casos bastará con esto pues loe componentes estarán semi-ensamblados).

Escribir en post-it todas las Historias de Usuario (ítems de trabajo) que se abordarán para conseguir la Lego City. En este documento tenéis una lista de ítems de trabajo sugeridos, agrupados por características y subcarácterísticas deseadas para la Lego City, ahí se señalan algunos matices adicionales para ítems. Se recomienda no poner directamente todos los ítems sugeridos uno en cada post-it, sino que agrupar algunos, para que esto obligue a trabajar en paralelo, dividir Historias de Usuario y/o crear tareas asociadas a dichas Historias de Usuario de mayor envergadura.

Poner todas las Historias de Usuario en la columna TO DO.

Sobre folios unidos con celo o sobre un papel más o menos amplio hacer un trazado de calles y un río en una esquina en diagonal.

Cuenta con unos 15 minutos para hacer toda la preparación indicada, intenta tenerlo todo preparado antes que lleguen los participantes.

El número recomendado de participante para esta actividad es entre 4 y 6, con menos serán poco evidentes ciertas situaciones y con más la actividad puede resultar caótica. En caso de tener un grupo más numeroso sugiero armar equipos que se turnen en cada uno de los round que se describen a continuación. Así, en el round participa sólo un equipo y el resto observa y comenta con el instructor las situaciones que se van presentando.

Primer Round

Explicar la visión de la Lego City en términos de características que se desea que ésta tenga. Pueden señalarse las sugeridas en el mismo documento indicado antes.

En este primer round no controlaremos tiempo (sin time-box). La idea es ilustrar Kanban y el interés en generar flujo de trabajo terminado. De paso el equipo conseguirá tener una noción del esfuerzo que implica el armado de componentes.

Dar por iniciado el round y el instructor (que se adjudicará el rol de Cliente o Product Owner) irá cogiendo post-it y los pasará a la columna DOING, de uno en uno, dando tiempo para que se cree la indecisión de los miembros del equipo respecto de si trabajar cada uno en un ítem (y esperar a que aparezcan más en DOING) o trabajar entre varios en un ítem. Comentar esta situación e indicar que los ítems pueden realizarse en conjunto o individualmente. Animar a que los participantes se auto-organicen. Seleccionar ítems variados en cuanto a su grado de especificación (que estén asociados a componentes que tengan instrucciones, que sólo dispongan de la imagen del resultado final y que no estén predefinidos).

Con las condiciones que he mencionado antes, bastaría con entre 15 y 20 minutos para que terminen los ítems. De todas formas, dejarlos que se tomen el tiempo que necesiten para ello, no presionarlos al respecto.

Advertir que los ítems no se deben quitar del panel y que cuando estén finalizados deben moverse a la columna DONE.

Ir comentando sobre la marcha respecto de las analogías de la construcción con legos y el desarrollo de software. Comentar el hecho que algunos ítems tienen especificaciones precisas, otros una imagen de referencia y otros deben crearse de forma aparentemente libre. Insistir en que según el caso debería ser más o menos crucial la interacción con el cliente para asegurar la aceptación final del componente.

Cuando esté todo lo propuesto construido y puesto en el trazado de la ciudad hacer una inspección objetando aspectos que no fueron acordados con el cliente y advirtiendo que por esto podrían no ser aceptados, sin embargo, por esta vez aceptarlos :-).

Segundo Round

Esta vez simularemos un sprint con un time-box de 10 minutos.

Antes de comenzar empujaremos al equipo a hacer estimaciones en minutos de cada uno de los items restantes en la columna TO DO. Con un rotulador escribirán la estimación sobre el post-it. Si un item tiene más de 10 minutos de estimación debería ser dividido o de antemano prever que deberá realizarse por más de unos o dos personas a la vez.

Una vez estimados todos los ítems de la columna TO DO, preguntar al equipo cuánto sería su capacidad, en este caso expresada en minutos de trabajo que pueden abordar en 10 min. Obviamente el máximo teórico será 10 por el número de participantes (por ejemplo, con 5 participantes tendrían un máximo de 50 minutos de trabajo por abordar). Sin embargo, se trata de una estimación en términos de tiempo ideal, es decir, debería ser menos que el máximo. Sugerir que consideren, por ejemplo alrededor de un 70% de capacidad respecto del máximo posible. Por ejemplo, si tienen 50 minutos máximos, que consideren sólo 35.

A continuación, el instructor irá pasando ítems a la columna DOING. El equipo llevará en cuenta la suma de estimaciones de los ítems en dicha columna e indicará al instructor cuándo se ha alcanzado o se estará apunto de sobrepasar su capacidad en minutos (para un sprint de 10 minutos).

Antes de comenzar el sprint hacer que el equipo reflexione respecto a si verdaderamente cree posible abordar todo el trabajo incluido en la columna DOING. En caso de no esta seguros acordar quitar ya ítems. No deberían valer frases del estilo "dejémoslo y ya veremos si alcanzamos a hacerlo". En caso de quitar (o añadir) ítems modificar la capacidad antes acordada.

Arrancar la cuenta regresiva e ir informando períodicamente el tiempo restante.

Estar atento a situaciones nuevas debido a la limitación de tiempo, por ejemplo, que recurran al cliente para acordar alguna reducción de dificultad en caso que se vaya complicando la construcción y se acabe el tiempo disponible.

Al terminar el tiempo el cliente revisar el trabajo que haya quedado incompleto. Podría aceptarse parcialmente definiendo un nuevo ítem correspondiente a la parte faltante, el cual se pondría nuevamente en la columna TO DO. Si el ítem en gran medida no está acabado o ni siquiera empezado devolverlo a la columna TO DO. Revisar además todo el trabajo añadido a la columna DONE y ser riguroso en cuanto a lo que pueda no estar completo o correcto, actuando de forma similar a lo hecho con los ítems que quedaron en la columna DOING.

Según los resultados de la revisión, modificar la capacidad del equipo, la cual se utilizará para el siguiente sprint.

Tercer Round

El tercer sprint pretende llegar a una situación de proceso controlado. Para esto el equipo habrá alcanzado una noción más realista de su capacidad y es de esperar que en este sprint se encuentre más cómodo, menos presionado por el tiempo.

El Produt Owner vuelve a poner en DOING ítems sin sobrepasar la capacidad del equipo.

Volvemos a simular un sprint de 10 minutos de time-box.

Conclusiones

Comentar brevemente los conceptos y situaciones que se presentaron en la actividad, entre ellos:

Kanban y la idea de flujo de trabajo terminado
El equipo self-organized y cross-functional
Las analogías construcción con Lego y desarrollo de software
Situaciones específicas de particionamiento de ítems, uso de tareas, trabajo incompleto, trabajo rechazado por el cliente, interacción y validación continua con el cliente
Algunos elementos de Scrum: roles (Product Owner y Development Team), Sprint, reuniones (Sprint Planning Meeting y Sprint Review Meeting, time-box, ítems de trabajo, capacidad del equipo.

Materiales

Una cantidad suficiente de Legos para mantener ocupado al equipo (más abajo se detallan los que utilizo y son suficientes para un equipo de máx. 6 personas), una paquete de post-it, rotuladores para escribir en ellos, una superficie donde los post-it se adhieran (obvio pero importante :-) ) y donde se puedan señalar tres columnas etiquetadas por TO DO, DOING y DONE.

Los Lego no son baratos. Esta actividad podría hacerse con otros elementos alternativos, incluso sólo con papel y lápiz haciendo dibujos de lo que se va a construir. Sin embargo, si tenéis la posibilidad de hacerlo con Legos os lo sugiero pues hay aspectos interesantes que tienes por defecto: la connotación de estar jugando pues es en sí un conocido juguete, el rango de posibilidades desde seguir una especificación de construcción hasta realizar algo totalmente salido de la imaginación y habilidad del participante, el desafío y competitividad/colaboración que despierta de forma natural, etc. Además, he preferido utilizar Lego pues mis hijos ya eran expertos en Lego y han estado muy contentos de participar en la compra y pruebas de los compomentes :-). A continuación presento la lista de componentes que uso en esta actividad. El costo aproximado ha sido 200 €, ... hasta ahora los considero bien rentabilizados :-). Esta es la lista del material que utilizo.

Algunos momentos de la actividad

Es importante resaltar cómo naturalmente se pueden en gran medida evitar los tiempos sin trabajo pues los agentes pueden ayudar a otros cuando terminan con su trabajo y no queda más trabajo por asignar. Esto es posible porque es un equipo cross-functional, "todos pueden hacer de todo" (que en este caso sólo se trata de construir con Lego).

En el siguiente tablero kanban utilizamos post-it de color verde pegados junto a las Historias de Usuario para representar tareas asociadas. Las etiquetas en rosa indicaban el nombre de quien estaba realizando la Historia de Usuario o tarea (podía haber más de un a persona asociada). De todas formas, como indiqué antes, en mis últimas aplicaciones de esta actividad con Legos la he simplificado dejando todos los ingredientes más específicos de Scrum y Kanban para otra actividad específica para ilustrar Scrumban.

Cuando se añade el "time-boxing" viene muy bien utilizar y poner visible un reloj con cuenta regresiva. Os recomiendo http://www.online-stopwatch.com/