Actividad: Scrum + Kanban + conceptos Equipo Self-organizing y Cross-functional

En esta actividad se ilustran las situaciones que se pueden enfrentar trabajando con Scrum + Kanban = Scrumban, es decir, escenarios de trabajo de un equipo que aplica Scrum, particularmente aquellos generados en la utilización de un tablero kanban.

Para simplificar nuestra actividad vamos a trabajar solo con un sprint abierto y el resto de los ítems pendientes en el Product Backlog. 

Preparación del Material

Material

Velcro en gorras y carteles

Velcro en ítems

Dorsales

En este fichero tienes los carteles para formar el tablero kanban y para poner en las gorras, además de los ítems. Te recomiendo pegarlos sobre cartulina para conseguir más resistencia y rigidez. Corta pequeños trozos de velcro y pega una sus caras a los carteles e ítems, la otra cara la pondrás en la pared y en el frente de las gorras. En lugar de utilizar gorras para los miembros del equipo (dependiendo de la audiencia, esto puede suponer alguna molestia), los carteles indicando la actividad que cada agente está realizando se pueden adherir con velcro en la parte inferior de cada dorsal.

Tienes que poner alrededor de seis trozos de velcro en cada columna para poder ir poniendo los ítems que lleguen a ese estado en la correspondiente actividad. El tablero que debemos preparar corresponde al siguiente diseño.

Este es un tablero kanban minimalista, reconoce sólo las tres actividades esenciales asociadas a un ítem de cambio en el producto (Definir, Programar y Testear). El trabajo de definición (idealmente y en gran medida) se realizará en el Product Backlog (este trabajo se denomina "grooming" del Product Backlog). Se procurará tener una lista ordenada de ítems en la columna Done, preparadas para ser incluidas en dicho orden en el siguiente sprint.. 

Considerar unos 15 minutos previos a la actividad para preparar el Scrumban en una pared poniendo todos los carteles y trozos de velcro.

El instructor desempeñará el rol de Scrum Master. Existirá un Product Owner y entre 3 y 5 miembros del Development Team. En caso de más participantes sugiero ir turnándolos en los diferentes sprints, quedando como observadores cuando no sea su turno.

Realizaremos 3 sprints. La actividad en total dura alrededor de una hora y media. En cada Sprint introduciremos ciertas variaciones para producir ciertas situaciones que deban ser comentadas.

Primer Sprint

Configuración:

• Sin estimaciones.
• Seguimiento basado solo en el tablero kanban
• Con pre-asignación de agentes (el equipo auto-organizado se distribuirá el trabajo antes de comenzar el sprint, acordando los ítems y actividades en los cuales trabajará cada agente). 
• El Product Owner realiza todo el trabajo de definición y ordenamiento del  Product Backlog.
• Roles fijos. Remarcar que cuando los miembros del equipo desempeñan un rol fijo se está contradiciendo la parte del concepto Cross-functional referente a promover que todos los miembros del equipo puedan realizar cualquier actividad, aunque puedan ser más especialistas en alguna de ellas. La otra parte del concepto Cross-functional se refiere a que todas las habilidades deberían estar dentro del equipo, esta asumiremos que la cumplimos.

En el Product Backlog ya se tienen algunos ítems en TO DO, en DOING y en DONE (en esta última columna al menos 6 ítems). En cada columna del Product Backlog remarcar que los ítems están ordenados de arriba a abajo, y que deben siempre cogerse en dicho orden.

Poner el cartel de Sprint Planning Meeting en una pared cercana al tablero y llevar al equipo a dicha posición. En la primera mitad del Sprint Planning Meeting se simulará el hecho que el Product Owner comenta y aclara los ítems que coge de la columna DONE de la actividad Definir del  Product Backlog y los pone en la columna TO DO de la actividad Programar (en el Sprint Backlog), esto se repite hasta que el Development Team indica que es suficiente respecto de su capacidad (en este caso no tenemos estimaciones con lo cual lo haremos "a ojo" y simplemente con 4 ítems pararemos). En la segunda parte de la Sprint Planning Meeting se simula que el equipo se organiza para trabajar durante el Sprint considerando los ítems incluidos. Remarcar el concepto de Self-organizing. Son los propios miembros del equipo quienes deciden cómo abordar el trabajo del sprint teniendo la posibilidad de crear tareas (trabajo técnico asociado a los ítema y que no requiere acordarlo con el cliente) para los ítems que considere conveniente hacerlo, en nuestro caso para no complicar la actividad no crearemos tareas haremos.

En este primer Sprint y para ilustrar típicas ineficiencias, se hará la pre-asignación de miembros a actividades de cada ítem a las actividades Programar y Testear), y además cada miembro tendrá un rol fijo (Programador o Tester). Tener en cuenta que no debería testear el mismo que ha programado. Para representar la pre-asignación, cada participante eligirá un avatar y los pondrá sobre las letras P y T que indican la actividad que realizará en los ítem. Aclarar también que las actividades de un ítem podrían abordarse con más de una persona trabajando en paralelo.

Arrancar el Sprint.

Cuando un miembro realice la actividad de un ítem debe poner un papel en su dorsal con el número del ítem y además mover dicho ítem a la columna DOING de la correspondiene actividad.

El Product Owner durante el sprint continuaría definiendo ítems para próximos sprints. Además, cada cierto tiempo añadirá nuevos ítems al TO DO del Product Backlog, o los moverá a DOING. El Development Team a demanda del Product Owner comentaría ítems de Product Backlog y antes de que se pasen a DONE deberían ser estimados por el equipo. . El Product Owner mantiene siempre ordenados los ítem del Product Backlog, en particular la columna DONE pues se trata de ítems perparados para ser incuidos en un sprint. Todo este trabajo de gestión del Product Backlog se denomina "grooming", y se realiza de forma constante en paralelo al trabajo del sprint en curso.

Resaltar y comentar los casos en los cuales un miembro del equipo queda "ocioso", a la espera de algún ítem que está en una actividad previa. En esta situación dicha persona podría acudir al Product Owner para ayudarle con el "grooming" del Product Backlog. También podría ayudar a algún compañero en otra actividad (que corresponda con su rol fijo) o incluso podría reemplazar a un compañero que había sido pre-asignado a un ítem.

En este primer Sprint, para simplificar las explicaciones, no haremos Daily Scrum.

Remarcar lo que ser haría en la Sprint Review Meeting (la revisión con el Product Owner del resultado del sprint).

Hacer la Sprint Retrospective Meeting comentando lo siguiente:

• Plantear como mejora el hacer pre-asignación sólo para algunos ítems. La pre-asignación puede resultar interesante cuando el desafío que implica un ítem requiere de un especialista. Pero su inconveniente es que resta flexibilidad y provoca tiempos de espera. En consecuencia para ce sensato que sólo se realice pre-asignación en cierto ítems.
• Destacar la inflexibilidad que constituye el desempeño de roles fijos, cuando un participante se ha quedado ocioso y no puede coger trabajo pendiente en actividades que no corresponden a su rol.
• Resaltar que una deficiencia que podríamos tener en este caso es que el Product Owner no tenga las habilidades y conocimientos para expresar adecuadamente los ítems, además de actuar como cliente esperamos que se un experto en requisitos. El Scrum Master debería apoyar al Product Owner enseñándole cómo hacerlo pero puede que con esto no baste para que lo haga. Además, probablemente el cliente ni siquiera esté dispuesto a asumir dicha carga de trabajo. Ante estos inconvenientes en el próximo sprint dejaremos el trabajo del Product Backlog en manos del Development Team, aunque el Product Owner se mantiene como responsable y encargado de tomar todas las decisiones importantes.
• Cuestionar el hecho que cuando se esté por terminar un Sprint, deberían existir suficientes ítems preparados para ser incluidos en el siguiente Sprint, de lo contrario o bien se producirá un parón antes de comenzar el próximo sprint, o nos veríamos obligados a incluir ítems que no están bien definidos. En consecuencia, debe reservarse cierto esfuerzo para hacer dicho grooming en paralelo al trabajo de implementación del sprint actual.

Segundo Sprint

• Sin estimaciones
• Seguimiento basado solo en el tablero kanban
• Sin pre-asignación, los agentes se asignarán a actividades cuando éstos vayan a realizar la actividad
• El Product Owner toma decisiones respecto de los ítems en el Product Backlog, sin embargo, el trabajo de definición y ordenamiento lo realiza el Development Team, colaborando con el Product Owner, quien mantiene la responsabilidad y la toma de decisiones más importantes.

Realizar la Sprint Planning Meeting.

Provocar interrupciones cortas, que no obligan a dejar el trabajo actual, y largas, aquellas que obligan a dejar el trabajo actual y ponerse en el nuevo, lo cual conlleva cambio de carteles en el dorsal y a marcar el ítem en el tablero kanban para señalar que ya hay alguien que ha comenzado a trabajar en él en la actividad correspondiente.

Recrear la detección de un fallo detectado en testeo. El ítem se devuelve DOING en Programar si es difícil continuar testeando en presencia de dicho fallo. Si el fallo no impide seguir testeando, se notificará al encargado de programar la WU que tendrá que corregir el fallo pero se continuaría testeando. Remarcar que éstas son situaciones de re-trabajo, y que podrían afectar a cualquier actividad.

Parar en algún momento para simular una Daily Scrum. Que cada miembro del equipo responda a ¿qué hice el día anterior (minunos antes)? ¿qué haré durante este día (próximos minutos)? ¿qué impedimentos tengo?

Hacer la Sprint Review Meeting. Resaltar que el mejor criterio para dar por buena una versión ("DONE" del sprint) sería que cada ítem tenga definida sus pruebas de aceptación y que éstas se hayan aplicado satisfactoriamente.

Realizar la Sprint Retrospective comentando lo siguiente:
Vamos a suponer que el compromiso de plazos y resultado del Sprint es muy rigido,  lo cual nos exige un seguimiento más preciso para anticipar desviaciones que pongan en riesgo el cumplir dicho compromiso. Así pues, no nos bastaría con el seguimiento básico ofrecido por la visualización del tablero kanban donde se ve el estado de cada ítem, sino que pasaremos a estimar el esfuerzo de los ítems en las actividades que podrían resultar más críticas en cuanto a esfuerzo (en este caso lo haremos sólo para la actividad Programar). Utilizaremos una gráfica Burndown para supervisar el grado de avance del sprint y hacer una previsión de cumplimiento en base al esfuerzo restante y el tiempo disponible hasta el fin del sprint.


Tercer Sprint

• Con estimaciones y seguimiento basado en esfuerzo restante
• Seguimiento basado en el tablero kanban y en la gráfica Burndown
• Sin pre-asignación de agentes a actividades
• El Product Owner toma decisiones respecto de los ítems en el Product Backlog, sin embargo, el trabajo de definición y ordenamiento lo realiza alguien del equipo, colaborando con el Product Owner quien mantiene la responsabilidad.

Cuando se requiere realizar un seguimiento diario y más preciso del estado de avance del sprint probablemente lo más indicado sea realizar estimaciones y re-estimaciones, y reflejar el estado de progreso en una gráfica Burndown. Como unidad de esfuerzo yo prefiero utilizar horas ideales (horas contínuas, sin considerar interruppciones) en lugar de puntos pues debido a que diariamente habría que preguntarse cuánto esfuerzo restante queda en cada ítem del sprint, me parece más razonable y sencillo establecer cuántas horas ideales quedan, en lugar de cuántos puntos.

Lo ideal sería que el equipo realizara la estimación de los ítems en el Product Backlog, cuando los ítems que están en la columna DONE de la actividad Definir, es decir, una vez que ya están definidos. Así, durante el sprint y parte del trabajo de gooming del Product Backlog, el equipo debería dedicar algún tiempo para estimar ítems próximos a ser incluidos en un sprint. Si no se estiman los ítems durante sprints previos, el equipo se verá obligado a hacerlo en la Sprint Planning Meeting, quizás demasiado tarde porque el ítem ya está siendo considerado para incluirse en el sprint.

Cuando pasamos a incluir estimaciones, debemos como contraparte tener una noción de la Capacidad. La Capacidad de un equipo es el esfuerzo que el equipo puede abordar satisfactoriamente en cierta unidad de tiempo. Si estimamos en horas ideales, la Capacidad podría establecerse en términos de horas ideales por semana. Las horas ideales por semana tendría como límite el número de horas contractuales semanales del equipo. Sin embargo, por tratarse de horas ideales, siempre estarán por debajo de dicho límite. La Capacidad es una medida histórica y que debe considerar posibles variaciones que la afecten, por ejemplo, el equipo, el producto, la tecnología, etc. Cuando se mantienen constantes dichos factores, la capacidad del equipo puede ser bastante sencilla de calcular y fiable respecto del histórico de los últimos sprints. Por otra parte, las estimaciones, a pesar de poder hacerse para cada actividad, recomiendo centrarse en las que podría ser cuello de botella, y en este ejercicio, para simplificar más aún vamos solo a estimar esfuerzo para la actividad Programar. Para adecuarlo a la duración de la actividad, haremos un sprint de 10 minutos y estimaremos en minutos ideales.

Para no complicarlo demasiado, supondremos que el equipo tiene una Capacidad de 30 horas ideale por semana y considerando un sprint de 3 semanas, con esto tendríamos una Capacidad de 90 horas para el sprint. Con esto, asignar estimaciones ficticias (entre 10 y 30 horas ideales) a los ítems en la columna DONE del Product Backlog, de forma que se tengan más ítems que los que se podrían introducir en el sprint (que sobrepasen en conjunto las 90 horas ideales que se podrían incluir).

Hacer la Sprint Planning Meeting cogiendo hasta un máximo de 90 horas ideales de esfuerzo.

Preparar la Gráfica Burndown, en el eje Y el esfuerzo restante y en el eje X los días del sprint. Dibujar el primer punto en el eje Y en la posición correspondiente al esfuerzo de partida. Trazar una línea de referencia desde dicho punto hasta el punto de esfuerzo 0 en el último día del sprint.

Arrancar el Sprint.

Detener el trabajo varias veces simulando diferentes días con los correspondientes Daily Scrum. Actualizar el tiempo restante de cada item tachando el valor antiguo y poniendo el nuevo. Llevar la suma del tiempo restante al gráfico Burndown como un nuevo punto en el día correspondiente e ir trazando una línea entre los puntos de esfuerzo restante.

Comentar en el Burdown respecto de desviación respecto del progreso ideal representado por la línea de referencia. Comentar los eventos que pueden afectar al esfuerzo restante, tales como: falta estimar algún ítem, se ha superado la estimación de un ítem y esto no se ha reflejado en su estimación restante, se ha re-estimado un ítem (incremento o disminución de esfuerzo), ítems añadidos o quitados del sprint, ítems eliminados o desestimados. No es necesario simular todo el sprint, es más interesante comentar la tendencia de esfuerzo restante en la gráfica Burndown.

Conclusiones

La realización de esta actividad es todo un desafío, sin embargo, el éxito está prácticamente asegurado pues es sin lugar a dudas entretenida. Aunque puede tener momentos un tanto caóticos por la cantidad de situaciones y dudas que surgen a la vez, haciendo las correspondientes pausas para comentar las situaciones se puede reconducir adecuadamente. Al respecto, es crucial no incluir muchos participantes en la actividad, no más de 5, y si los asistentes son más de 5 se pueden ir intercambiando los participantes en cada Sprint. El resto de los asistentes que no está trabajando en el sprint debe estar atento para detectar situaciones y hacer comentarios como observadores de la actividad.

Para sacarle el máximo de provecho a esta actividad es necesario tener presente el catálogo de situaciones que pueden presentarse para estar atento a cuando surgen y comentarlas. En este sentido, podéis consultar una lista de debilidades para un tablero kanban físico (de pared).

Esta actividad está principalmente enfocada a equipos de desarrollo de software. En el caso de equipos trabajando en otros contextos, o como actividad introductoria para desarrolladores de software, recomiendo la actividad  Kanban y Scrum construyendo una Lego City.

Espero que este material os sea de utilidad. Si tienes dudas o sugerencias, o simplemente quieres compartir experiencias acerca de la aplicación de esta actividad no dudes en contactarme.

Fotos de la Actividad

Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com

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/

Otros momentos de la actividad ...

Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com

¿Cuando y cómo el trabajo de arquitectura cobra protagonismo en el contexto ágil?

Existen variadas definiciones o perspectivas del concepto "arquitectura". En este post el concepto arquitectura se refiere a la organización externa e interna del producto software. Organización externa en cuanto a los requisitos del producto e interna en cuanto a los elementos/capas/componentes de código del producto.

Una buena arquitectura facilita no sólo el desarrollo del producto sino que especialmente su mantenimiento, facilitando las modificaciones, pruebas y reutilización.

Una de las diferencias técnicas más destacables del enfoque ágil con respecto al tradicional es que en el primero la arquitectura del producto se va definiendo y mejorando con refactorización a lo largo del proceso de desarrollo. En cambio, en el enfoque tradicional la arquitectura en gran parte se establece tempranamente, antes de entrar en las iteraciones de construcción del producto. Ambas estrategias son válidas de cara a conseguir al final una buena arquitectura. En el caso del enfoque ágil su estrategia le permite casi de inmediato comenzar a programar el producto, mientras que en el enfoque tradicional se dedica un tiempo considerable al establecimiento de dicha arquitectura (en base a modelado y especificación del producto que se va a construir) antes volcarse en la programación. La inversión temprana en arquitectura pretende evitar en lo posible que cambios durante el desarrollo tengan alto impacto en lo ya implementado. En el enfoque ágil se asume este riesgo asociado al impacto de los cambios y se paga con continua refactorización.

Las situaciones en las cuales es muy útil realizar un trabajo previo de arquitectura y el cómo hacerlo es un tema escasamente tratado en el ámbito ágil. Gran parte de la literatura ágil está centrada en la gestión de cambios (llamados Ítems, Historias de Usuario, Unidades de Trabajo, o similar) que son de mucha granuralidad, muy pequeños, lo cual ocurre normalmente cuando el producto ya ha alcanzado una cierta estabilidad en su arquitectura, es decir, en  cuando cada cambio individualmente no requiere gran trabajo de arquitectura, especialmente pues se trata de pequeñas mejoras o correcciones de fallos. Sin embargo, cuando se trata de un cambio de gran envergadura (reconocido como "Historia de Usuario Épica"), o en particular cuando se debe establecer y llevar a cabo la primera entrega del producto (primera puesta en producción), es altamente recomendable definir los Ítems con una perspectiva más global e integradora, junto con establecer una arquitectura global que sea adecuada para soportar en conjunto a dichos Ítems.

Si para desarrollar un producto sólo necesitamos definir y concentrarnos en un sprint se simplifica significativamente la planificación y seguimiento (y su explicación). Esta es la situación típica de mantenimiento en la cual cada versión (resultado de un sprint) suele coincidir con una entrega (versión pasada a producción). Todos los cambios enfrentados durante el desarrollo bien se incluyen en el sprint actual (sólo en caso que sean imprevistos urgentes) o bien se incluyen y ordenan dentro del Product Backlog. Sin embargo, cuando enfrentamos el desarrollo de la primera entrega de un producto, o cuando se realiza un cambio de gran envergadura en un producto (posterior a su primera entrega), probablemente se tendrá que trabajar durante varios sprints. En este caso es muy recomendable realizar un trabajo previo de arquitectura tanto desde el punto de vista externo (requisitos y su organización) como interno (componentes de la estructura interna). Este trabajo no tiene porqué igualarse al realizado por un enfoque tradicional, al menos en cuanto a detalle y duración. Para mantener el espíritu ágil, dicho trabajo en arquitectura debería ser más general, corto e intenso en comunicación dentro del equipo.

Con lo anterior hemos establecido el "Cuándo" la arquitectura coge protagonismo, que es precisamente cundo se trabaja cambios asociados a nuevos requisitos o importantes modificaciones de funcionalidad, y particularmente cuando éstos son de gran envergadura, es decir, pueden tener un alto impacto en el producto. Veamos ahora el  "Cómo".

Frente a un nuevo desarrollo o un cambio de envergadura, antes de comenzar a definir Ítems que descomponen dicho trabajo (Historias de Usuario), el equipo se debe concentrar en establecer la Visíón del Producto (o del cambio). Esto conlleva identificar la motivación para realizarlo, problemas que resuelve, necesidades que satisface, características principales, tipos de usuarios que se verán afectados. Desde el punto de vista interno debe definirse a modo general qué capas, frameworks, componentes u otros elementos tendrán que desarrollarse y/o integrarse.

Para este trabajo previo podemos definir un ítem del tipo Épica o realizar este trabajo de visión y arquitectura en paralelo a los sprints que estén en curso (en el caso de un nuevo requisito o mejora de cierta envergadura). Incluso, si se trata de un producto nuevo, este trabajo puede plantearse como una breve fase previa a la planificación de la entrega y al comienzo del desarrollo iterativo.

Dos comentarios finales:

• En muchos contextos de desarrollo ya tiene un reconocimiento explícito el rol "Arquitecto". ¿que hacemos con él? :-). La respuesta sencilla y coherente con el planteamiento de Scrum sería no reconocer ese rol como un título fijo para una persona. El arquitecto estaría dentro del equipo de desarrollo (en rol genérico Development Team) pero sería reconocido como especialista en arquitectura. Así, cualquier miembro del equipo podría realizar trabajo de arquitectura pero teniendo como apoyo al especialista en arquitectura cuando se requiera por las características del cambio involucrado.
• El trabajo de mejora y supervisión contínua de la arquitectura es importante en todos los cambios del producto, sin embargo, se hace más patente en los grandes cambios. Este trabajo puede hacerse de forma ágil, en el sentido que su intensidad y profundidad sea acorde al riesgo del posible impacto del cambio, y acorde también con el consecuente "castigo" que conllevaría la correspondiente refactorización. No hay recetas específicas, pero claramente conocemos los extremos: invertir mucho en arquitectura para rentabilizarlo (o no rentabilizarlo) en el futuro, o invertir poco en arquitectura y pagar mucho (o poco) por el refactoring en el futuro (debido a la llamada Deuda Técnica o Technical Debt). Lo sensato sería evaluarlo para cada situación y tomar la decisión asumiendo el correspondiente riesgo.

Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com

Entrega (release), Iteración (sprint), Proyecto: ¿cuál es su relación?

Una pregunta recurrente que se hace gente que viene de gestión de proyectos "tradicional" cuando enfrenta la implantación de un enfoque ágil es ¿cuál es la equivalencia del término "proyecto" en este contexto?. Los conceptos son importantes, especialmente cuando se trata de explicar (e implantar) nuevos enfoques. Si bien no me atrevo a ser categórico, al menos puedo aportaros mis definiciones al respecto, las cuales hasta ahora he aplicado y me han resultado efectivas.

En cualquier enfoque ágil un pilar fundamental es realizar entregas (releases) frecuentes al cliente, es decir, poner en producción nuevas versiones del producto. El trabajo de desarrollo es organizado en iteraciones (sprints) cuya duración no debería ser superior a un mes (la frecuencia recomendada por XP o Scrum). Cuando el producto ya está en producción (se ha hecho al menos una entrega al cliente) las siguientes entregas podrían coincidir con las iteraciones, es decir, cada versión resultante de la iteración podría ser puesta en producción. Sin embargo, cuando se trata de la primera entrega del producto, o cuando se trata de una reforma de envergadura, probablemente no será suficiente con un mes de trabajo para conseguir un nivel operacional mínimo para ponerla en producción. Así pues, para respetar el hecho de que cada iteración (sprint) no debería extenderse más allá de un mes, en el caso de entregas que no puedan desarrollarse en una sola iteración, éstas requerirán ser abordadas en una serie de iteraciones.

La primera entrega del producto podría coincidir con la idea tradicional de proyecto de desarrollo. Pero una vez que el producto está en producción el objetivo será conseguir una siguiente entrega a través de una o más iteraciones. Estas siguientes entregas podrían llamarse "proyectos" pero parece más natural llamarlas entregas, o simplemente versiones cuando coinciden con ser el resultado de una sola iteración.

Hay una situación particular en la cual el concepto de proyecto resulta adecuado en el contexto de desarrollo iterativo e incremental. Esta es cuando se hace un cambio de envergadura en el producto, el cual obliga a organizar una serie de unidades de trabajo en varias iteraciones, quizás incluso dedicando recursos específicos para dicho cambio. Así, durante sucesivas iteraciones, de forma exclusiva o en conjunto con otros cambios, se lleva a cabo el trabajo asociado al proyecto. Los cambio asociados al proyecto podrían incluirse en las posibles entregas que se realicen durante la duración del proyecto o pueden hacerse disponibles sólo en la entrega que coincide con el término del proyecto. En el ámbito ágil este concepto de proyecto coincide con el término theme, el cual se refiere a un conjunto de Historias de Usuario relacionadas en cuanto a la funcionalidad o características que involucran.

Según lo explicado, queda en evidencia que cuando se utiliza un enfoque iterativo e incremental, el foco se centra en el producto más que en un determinado proyecto asociado al producto. Este matiz es similar al que se puede establecer al diferenciar un Product Manager respecto de un Project Manager. El trabajo del Product Manager está más orientado a los clientes del producto y dicho trabajo persiste mientras existe el producto. Por contraparte, la duración del trabajo del Project Manager es la duración del proyecto y su interés se centra en la gestión exitosa del proyecto, la cual debe estar alineada con la visión del producto pero restringida a unos plazos, alcance y costos específicos del proyecto. En Scrum el Product Owner tiene ingredientes de ambos, de Product Manager y de Project Manager, pero en mayor medida se acerca al primero.

Finalmente, ¿cómo se lleva a la práctica el concepto de proyecto cuando se trabaja con ítems (unidades de trabajo) en el Product Backlog o ítems en una determinada iteración (en el Sprint)?. En mi experiencia ha sido suficiente con asociar a un ítem su proyecto (si lo tiene) y luego al consultar ítems poder aprovechar dicho dato para realizar agrupaciones, filtros y selecciones de ítems. Otra característica que nos ha resultado útil es que un proyecto pueda tener asociado trabajo en diferentes productos. En este caso, cada producto tiene sus propias unidades de trabajo, y contando con el dato del proyecto se pueden tomar decisiones de coordinación entre las versiones de varios productos. En TUNE-UP Process estas funcionalidades están disponibles, y además se ofrece la posibilidad de realizar un seguimiento detallado del proyecto mediante un dashboard para este fin, el cual incluye entre otra información una gráfica Burndown para el proyecto, la cual permite supervisar su alcance global, es decir, más allá de la supervisión de cada sprint.



Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com

Gráficas Burndown: ¿cómo rentabilizar el esfuerzo asociado a su elaboración?

Este post es un resumen del artículo "Seguimiento ágil de proyectos de desarrollo de software utilizando Gráficas Burn Down", publicado por María Isabel Marante, Maria Company y Patricio Letelier en las JISBD 2011. Artículo completo disponible en: http://bit.ly/soy0fA

Las Gráficas Burndown han sido impulsadas por la metodología ágil Scrum, en la cual son el artefacto protagonista para el seguimiento de cada iteración. Una Gráfica Burndown muestra la evolución diaria del esfuerzo restante para finalizar el trabajo acordado con el cliente en cada iteración. Aunque esta gráfica parece a priori muy sencilla, para que su uso sea efectivo requiere superar los siguientes desafíos: estimar el trabajo, y  diariamente  recolectar y consolidar dichas estimaciones. Adicionalmente, para poder interpretar correctamente una Gráfica Burndown, es necesario contar con información complementaria respecto de eventos diarios tales como trabajo añadido o quitado del sprint, estimaciones sobrepasadas, ajustes realizados a la estimación, etc. Además, si la información está incompleta, desactualizada o incompleta la gráfica tendrá poco o nulo valor, corriendo el riesgo de tomar decisiones erróneas al hacer interpretación de la gráfica con esas deficiencias. Las carencias en los aspectos mencionados han provocado que las Gráficas Burndown no se estén aplicando o no estén resultando tan efectivas como se esperaba. Este post ilustra cómo hemos integrado las Gráficas Burndown en la metodología TUNE-UP Process y su herramienta de apoyo Worki, y cómo hemos superado los obstáculos antes indicados.

Worki ofrece una Gráfica Burndown para cada sprint de un producto o para un Proyecto (un conjunto de unidades de trabajo que posiblemente se implementarán en diferentes sprints), junto con una tabla y gráfica de Eventos Diarios con información complementaria para la correcta interpretación de la gráfica. 

En TUNE-UP y Worki denominamos Unidades de Trabajo (UT) a los ítems de trabajo o Historias de Usuario. Si el contexto de trabajo requiere un seguimiento cuantitativo se realizarán estimaciones en Puntos u Horas Ideales para cada UT dentro del Sprint y/o Proyecto. En el caso de Horas Ideales se pueden estimar todas las actividades por las cuales pasará la UT (las columnas del tablero kanban que mostrará el estado de la UT). Sin embargo, en nuestra metodología recomendamos comenzar estimando solo una actividad asociada a la UT, por ejemplo, estimar solo el tiempo de Programar, la cual es la actividad usualmente más determinante a la hora de implementar una UT.

La siguiente figura muestra la gráfica Burndown de Worki, podría tratarse de un período de tiempo asociado a un Sprint o a un Proyecto, lo que cambia es el período de tiempo que corresponda.

Nuestra gráfica incluye realmente tres gráficas en una; la gráfica básica Burndown (línea roja ilustrando el tiempo restante), la gráfica Burn Up (línea azul ilustrando el tiempo invertido acumulado), y la gráfica de Tiempo Estimado Total (línea verde ilustrando el tiempo total estimado cada día). Además, para apoyar la interpretación de la gráfica Burndown se traza una línea de referencia desde el primer día con mayor tiempo estimado restante (normalmente el primer día del período) hasta el último día en el cual el esfuerzo restante debería ser cero. Esta línea diagonal estaría suponiendo que la Velocidad es constante. Así pues, al disponer en una misma gráfica los esfuerzos estimados, invertidos y restantes, se facilita la interpretación del estado del Sprint y cómo se ha ido desarrollando. Situaciones tales como una bajada o subida pronunciada del esfuerzo restante podrían visualmente explicarse por una correspondiente bajada o subida en la línea de esfuerzo estimado, o bien en una subida o bajada en la línea de esfuerzo invertido. Sin embargo, la confirmación de estas interpretaciones, como veremos a continuación, exige contar más información respecto de los eventos que pueden haber ocurrido entre dos puntos consecutivos de la gráfica. Si para estimar se está trabajando con Puntos en lugar de Horas Ideales la gráfica Burndown solo require la contabilización de Puntos asociados a trabajo no terminado. La siguiente gráfica muestra la gráfica Burndown en puntos para la misma situación de la gráfica anterior.

Siendo la misma situación de trabajo vemos que la gráfica Burndown en Puntos es diferente a la construida con Horas Ideales. La razón es que las Horas Ideales restantes se reducen con el solo hecho de invertir tiempo, sin embargo, los Puntos descienden solo cuando se termina un trabajo, es decir si un ítem tiene una estimación de 5 Puntos, estos solo se restarán cuando dicho ítem esté finalizado (independiente de cómo se esté invirtiendo tiempo en él). De esta forma, la gráfica Burndown en Puntos promueve, además de un progreso continuo disminuyendo la cantidad de trabajo por realizar, que ese esfuerzo se corresponda con ítems de trabajo terminados. Así se desincentiva la tendencia a trabajar en paralelo sin terminar continuamente, acumulando la terminación de todos los ítems a la vez hacia el final del período de Sprint o Proyecto. Si acumulamos la terminación de ítems al final del período aumenta el riesgo de detectar tardíamente imprevistos y retrabajo, sin tener margen de reacción.

Aunque la gráfica Burndown nos da pistas claras del progreso de trabajo, para su correcta interpretación es conveniente conocer los eventos que diariamente se producen. En Worki, cada día a una cierta hora configurable se hace una snapshot del estado de las UT y con ella se calculan diferencias con respecto al día anterior. A continuación, se describen los eventos que consideramos importantes reunidos en dos grupos, explicando en cada caso el efecto que tiene sobre el cálculo del esfuerzo restante.

Eventos que directamente invalidan la lectura del esfuerzo restante 

• Actividad con estimación sobrepasada (solo aplicable cuando se usan Horas Ideales). El esfuerzo invertido en la actividad sobrepasa la estimación, lo cual llevaría a un esfuerzo restante negativo, por esto en Worki se considera esfuerzo restante igual a cero hasta que se corrija esta anomalía introduciendo la correspondiente reestimación.
• Actividad sin estimación. La actividad no ha sido estimada, con lo cual la información global de esfuerzo restante está incompleta, se está visualizando en la gráfica menos tiempo restante (o Puntos) de lo que efectivamente queda por hacer.

Eventos que provocan una variación en el esfuerzo restante observado

• Cambios del esfuerzo invertido. El esfuerzo invertido se ha modificado. Por ejemplo, se había registrado 10 horas de trabajo pero luego se corrigieron cambiándose por 5 horas. 
• Ajuste en Estimación. Incremento o Decremento de la estimación. Es imprescindible que cuando se prevea que la estimación no se cumplirá, inmediatamente se realice una reestimación.
• Introducción de estimación faltante. Indica que se ha estimado una actividad que el día anterior no tenía estimación.
• UT nueva. La UT no existía el día anterior, se ha creado y añadido al Sprint o Proyecto, añadiendo su correspondiente esfuerzo estimado. 
• UT añadida. La UT ya existía y se ha añadido al Sprint o Proyecto, añadiendo su correspondiente esfuerzo estimado.
• UT eliminada. Desaparecerá la estimación de dicha UT y también sus registros de tiempo invertido, provocando los correspondientes decrementos.
• UT desestimada. Se considera que su esfuerzo restante es cero.
• UT terminada. Se considera que su esfuerzo restante es cero (aunque no se haya alcanzado su estimación en horas). En el caso de estimar usando Puntos simplemente se descuentan todos los Puntos de la UT. 

Por otra parte, disponer de información más detallada respecto del progreso del trabajo y de los eventos ocurridos durante cada Sprint o Proyecto aporta información útil para reuniones de retrospectiva, ayudando a establecer acciones de mejora y posteriormente apoyar la evaluación de su resultado mediante la comparación de datos de diferentes Sprints y las tendencias asociadas.

Pero, ¿Qué sucede por ejemplo si para construir estas gráficas se debe invertir tiempo extra en la recolección y procesamiento de la información asociada? ¿Y si el equipo no se interesa en utilizar esta información gráfica para tomar decisiones respecto de sus compromisos? La clave está en la automatización de la elaboración de estas gráfica y en ofrecer mecanismos que faciliten el registro de la información, además de promover que el equipo se autogestione y se apoye en esta información cuantitativa para asegurar el cumplimiento de sus compromisos. El desafío es inculcar en el equipo la disciplina de estimar (y reestimar oportunamente) y registrar su inversión de tiempo en la(s) actividad(es) que necesitamos contrastar con las estimaciones. Si se consigue esto el equipo día a día dispondrá de la gráfica Burndown que le permitirá evaluar el progreso y advertir posibles carencias en su Capacidad de equipo para poder llegar a terminar el trabajo en el plazo comprometido. 


Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com