Swarming, todos para uno y uno para todos!

Sé que por ahí hay muchos artículos sobre esto, pero como hace poco salió el tema en una conversación que tuve y aún se piensa que es imposible enfocar los esfuerzos de todo un equipo en resolver un solo problema, quise escribir un poco al respecto.

Todo el equipo Scrum trabajando en una sola cosa

La práctica donde todos los miembros del equipo trabajan sobre la misma tarea, actividad, problema o historia de usuario (también conocida como swarming) suele aplicarse cuando el equipo y la organización han alcanzado un nivel de madurez en donde han entendido que el objetivo del equipo NO es completar historias de usuario si no entregar valor al cliente/usuario final (que no es el Product Owner). Incluso a este punto, también han entendido que las historias de usuario no son parte de Scrum, son solo una forma de describir lo que queremos que tenga el producto que estamos desarrollando en un lenguaje que nos permita a todos entender lo mismo y por ende entendernos mejor a la hora de definir eso que dará valor al cliente/usuario final. Un equipo Scrum lo bastante maduro y experimentado entiende que es más importante completar una tarea antes de empezar otra.

Un equipo Scrum lo bastante maduro y experimentado entiende que es más importante completar una tarea antes de empezar otra.

También es cierto, que no siempre se puede aplicar esta técnica y que tampoco puede ser impuesta al equipo, por ejemplo, por un jefe que fue a un curso donde le comentaron acerca del swarming y lo bueno que es que los equipos lo apliquen o por un Scrum “Manager” Master aka Project Manager que lo escuchó en un Meetup. La decisión de aplicar o no swarming debe ser única y exclusivamente del equipo de desarrollo (equipo auto organizado y auto gestionado) y dependerá de los objetivos que se hayan trazado para el Sprint que estén trabajando y los objetivos de negocio que tengan que cumplir.

Es aquí, donde una persona como el Scrum Master puede entrar en acción y proveer al equipo del conocimiento necesario para conocer y entender sobre swarming y otras prácticas de colaboración y trabajo en equipo por objetivos como Pair Programming, Mob programming, Mob Testing, (que podría escribir más adelante sobre ellas) prácticas que promueven que el equipo se enfoque en completar las actividades más prioritarias o que generan más valor al producto y al cliente/usuario final, enfocando el esfuerzo de uno, dos o incluso todo el equipo en completarlas, esto siguiendo los principios de Lean (eliminando desperdicios) y Kanban (limitando el WIP).

Éste tipo de técnicas normalmente van en contra de la naturaleza de las organizaciones (las que aún no han entendido o conocen sobre agilidad) y es difícil de comprender el valor real que aportan y aplicar de forma efectiva, de ahí que es necesario que para que resulten, la cultura en la organización debe cambiar.

También es cierto, que este tipo de prácticas si no se aplican de forma correcta ni por personas que entienden el objetivo de las mismas y el valor que ofrecen, pueden resultar en todo lo contrario a un resultado positivo y convertirse en una medida de perder el tiempo en el equipo, no llegando a cumplir los objetivos.

Entre las ventajas que nos puede aportar una práctica como el swarming están:

• Alineación. Todo el equipo toma parte en el desarrollo.
• Reglas de codificación. Todo el equipo define normas de codificación y reglas de calidad de software.
• Aprendizaje, traspaso de conocimientos. Los programadores con menos experiencia, aprenden más y mejor de los programadores más senior.
• Durante el desarrollo de esta técnica de trabajo se evitan reuniones de alineamiento, puesto que ya se está trabajando y desarrollando sobre la funcionalidad.
• Se evitan problemas de comunicación.
• Se evitan problemas de toma de decisiones, las toma el equipo al completo

Y por mencionar algunas desventajas:

• Requiere madurez del equipo y la organización.
• Requiere de conocimiento y mucha práctica para que funcione.
• No tiene mucho sentido en equipos muy grandes.
• El Product Backlog debe estar realmente priorizado para que el equipo no invierta tiempo en una tarea que no es la más prioritaria.
• Los miembros más experimentados pueden sentir que no son tan productivos como deberían.

Como conclusión, es importante entender que la razón de ser de un equipo Scrum no es el completar historias de usuario, sino, el entregar valor al cliente/usuario final. Un buen equipo Scrum adopta el mantra “termina de empezar, empieza a terminar”.  Si el equipo tiene un Product Backlog bien priorizado, y se dedica a hacer swarming con la historia que está más arriba en la lista (la más prioritaria) se estaría asegurando que entregará aquello más importante, aquello que está esperando ese cliente/usuario final como lo próximo que debe tener el producto.

Un buen equipo Scrum adopta el mantra “termina de empezar, empieza a terminar”.

Para finalizar les comparto un artículo de Javier Garzas del 2016 que explica un poco más sobre la práctica del swarming que no es nueva:

https://www.javiergarzas.com/2016/11/swarming-one-piece-continuous-flow.html