Agility at work: 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