El importante y desconocido Swarming, "flujo continuo de una sola pieza" o One-Piece Continuous Flow

Lo de Swarming, cuya traducción es algo así como “enjambre”, es una estrategia militar que consiste en atacar al enemigo con muchas unidades autónomas.
Quería hoy postear sobre esto, porque aunque es muy antiguo… creo que se olvida / desconoce en demasiadas ocasiones. Si sigues Scrum desde hace tiempo, y lo haces bien, consciente, o inconscientemente, habrás aplicado con frecuencia algo llamado Swarming o «flujo continuo de una sola pieza» (One-Piece Continuous Flow).
La idea es dedicar todos los esfuerzos a una única historia, entonces, todo lo necesario para completarla se hace tan en paralelo como sea posible. Además, cada miembro del equipo se centra en una sola historia de usuario a la vez, todo el mundo debe ayudar a que se termine la historia (item mejor dicho) de mayor prioridad.
Esto tiene varias ideas detrás…
– Tener abiertas demasiadas cosas a la vez, reduce la efectividad por los cambios de contexto, cosas que se empiezan, no se terminan, se empiezan otras, vuelta a la primera, vuelta a pensar en qué estado quedó, etc. Esto hace sus años que lo hablamos, 2013, referenciando al mítico Weinberg, en  trabajar en más de una tarea (ya no digo proyecto) a la vez genera pérdidas de tiempo y disminuye la productividad.
– …por estas razones, las de evitar el cambio de contexto, y el desperdicio al que ello conlleva, que Kanban límite el máximo de trabajo en el proceso, el WIP, siendo esto que aquí estamos hablando, el  Swarming o «flujo de una sola pieza», una alternativa al WIP de Kanban.
– El tiempo entre el momento en que el equipo comienza a trabajar en una historia de usuario y está terminada (Definition of Done superado) es lo más corto posible.
– La idea es más bien trabajar todos juntos para cerrar algo… más que trabajar cada uno en sus tareas (Sprint backlog) y que al final, tareas se vayan terminando pero items (Product Backlog) no. Los Dailys son una herramienta importante en todo esto, para enfocar al equipo.
– En relación al anterior, el Swarming lleva a aumentar la multifuncionalidad del equipo (yo leería aquí … Los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad)
Y dicho esto, el Swarming o «flujo de una sola pieza» nos implica, implica al equipo, a ordenar las tareas del Sprint Backlog, saber qué va primero, saber en qué poner primero todos los esfuerzos, que va después, teniendo en cuenta que  el Product Owner previamente nos ha dejado priorizado el Product Backlog, haciéndonos saber cuál es el item del Product backlog más prioritario.
Es decir, que como sabemos cuál es el item más prioritario del Product Backlog, de ese item el equipo deriva las tareas necesarias para completarlo… y esas tareas debieran ser las más prioritarias del Sprint Backlog.

El Patrón Rey – Sirviente

En relación, y por esto, Henrik Kniberg, autor de “Scrum y XP desde las trincheras” (Entrevista a Henrik Kniberg), creó el patrón Rey – Sirviente, que, simplificádamente, consiste en lo siguiente:
– Cualquiera que esté trabajando en la historia (item) de mayor prioridad es Rey y…
– Todos los demás miembros del equipo son sirvientes.
– Si quieres ser uno de los Reyes… tienes que ayudar con la historia de máxima prioridad.
– Cuando un Rey necesita ayuda, los siervos ofrecen inmediatamente sus servicios.
– Un Siervo no puede interrumpir a un Rey.
– Tan pronto como la historia de máxima prioridad está terminada, cualquiera que trabaje en la siguiente historia es ahora Rey.

Terminando (o continuando)

Por supuesto, todo esto del Swaming no es un tema exclusivo del mundo ágil, y, obviamente, existen muchos trabajos previos (puedes encontrar mucho en Lean, en el método de Toyota, etc.), por lo que puedes profundizar y leer mucho sobre esto que aquí en el post apenas he introducido.
Así que esto…. para empezar, porque el tema requiere y me dará para más post…

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

8 comentarios en “El importante y desconocido Swarming, "flujo continuo de una sola pieza" o One-Piece Continuous Flow”

  1. Me gusta lo del patrón Rey, y si además utilizamos una corona de cartón del Burger King le damos el toque divertido y visual.
    En mi día a día creo que sería una práctica, aunque aislada ya que no somos ágiles en ningún sentido, muy poderosa; porque las interrupciones desde múltiples sitios (incluso las propias con nuestro móvil) es nuestra gran contaminación de la que creo nadie se libra.

  2. No conocía este concepto del ‘swarming’, pero utilicé una fotografía de una bandada de estorninos volando para explicar una de las bondades de un modelo de gestión adaptativo: todos a una, como en Fuenteovejuna 🙂

  3. Muy buen post, voy a implementar eso de rey y sirviente, me parece interesante no interrumpir a las personas encargadas de tareas de mayor prioridad

  4. Buen artículo Javier, en tu línea. Pero creo que la primera frase está equivocada. Creo que el swarming militar y el SRUM swarming no tienen nada que ver, excepto el nombre. El swarming como concepto castrense, consiste en romper un gran equipo en pequeñas unidades (algo parecido a dividir el equipo en múltiples equipos) independientes. Estas unidades se comunican con las otras para pasarse información, pero son autónomas en sus decisiones. Así el enemigo queda desconcertado porque no sabe cuantos hay, no ve un orden en el otro lado, y eso le hace cometer errores. En Scrum es más parecido a un enjambre de abejas que van todas al mismo campo de flores. Y hasta que no lo agotan (o sale otro mejor) no van a otro. Es como si todos los miembros del enjambre tuviesen una única mente y se dedicasen a una cosa.
    Y quizás me ha faltado la principal ventaja, que es el minimizar el efecto de cambios o detección de defectos. Si el equipo trabaja en 4 historias a la vez, y las entrega en 4 semanas, podría ir con las historias una a una a 1 semana por historia. Al entregar la primera se podría ver que hay un error de concepto, y el product owner podría redefinir las prioridades del sprint porque el resultado no es el que se esperaba (a lo mejor esa pantalla tarda 5 segundos en cargar y eso cambia todo).
    Y por último me falta también el principal problema, el mito del hombre-mes, o la famosa frase de que nueve embarazadas no dan un bebe en un mes. A veces poner a todos en la misma historia repercute en la productividad.

    1. Muy interesante este tema del Swarming, sin embargo en mi caso, no se podido ver la forma de implementarlo, tenemos 4 miembros del dev. team (2 back y 2 front), a la fecha a sido imposible conseguir que las tareas de una historia puedan ser desglosadas para que los 4 miembros estén trabajando o aportando a terminarla cuanto antes. espero puedan compartirme su experiencia.
      saludos.

    2. Muy interesante este tema del Swarming, sin embargo en mi caso, no se podido ver la forma de implementarlo, tenemos 4 miembros del dev. team (2 back y 2 front), a la fecha a sido imposible conseguir que las tareas de una historia puedan ser desglosadas para que los 4 miembros estén trabajando o aportando a terminarla cuanto antes. espero puedan compartirme su experiencia.
      saludos.

  5. Pingback: Que es Swarming - Agile Coach Como trabajar en modelo Swarming.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *