Escalar Agile sin frameworks (3) – Aumentan los equipos

Tiempo aproximado: 10 min.

Este artículo forma parte de la serie “Escalar Agile sin frameworks” que puedes encontrar aquí a medida que la voy completando.


Varios equipos para un único producto

En el capítulo anterior navegamos la tensión que provoca, en una organización con un único equipo, la necesidad de trabajar en más de un producto o proyecto. En este artículo vamos a explorar otra tensión: la que provoca, en esa misma organización, el aumento del número de equipos trabajando en un único producto. Igual que en en el artículo anterior, vamos a empezar viendo qué sucede cuando pasamos de un equipo a dos y luego seguiremos aumentando.

Dos equipos para el mismo producto

A medida que un producto aumenta su complejidad o tenemos que producir funcionalidades a una mayor velocidad, lo normal es incorporar nuevos miembros al equipo. Esto sólo es válido cuando la tarea a realizar se puede particionar de manera que sus partes se realicen de manera completamente independiente. Es el caso que ya vimos en los primeros párrafos del artículo anterior y que Fred Brooks ejemplifica en “The Mythical Man-Month” con su conocidísima frase: «9 mujeres no pueden tener un bebé en 1 mes». 1 En el mismo capítulo de ese libro, Brooks hace un repaso de los factores que afectan a la duración de una tarea cuando añadimos más personas al equipo y concluye con su famosa Ley de Brooks: «Añadir más efectivos a un proyecto de software que va retrasado, lo retrasa más». Como veremos más adelante, esto mismo también es válido si en vez de individuos hablamos de equipos.

Imagina que nuestro único producto ha crecido mucho en complejidad. Quizás ya hemos aumentado el número de personas en el equipo hasta un punto en el que no nos queda más remedio que dividir el equipo original en dos. También podría haber sucedido que nos pidan “producir más rápido”. Puede que haya consecuencias indeseadas si llegamos tarde a una cierta fecha. La solución podría ser la misma que antes: aumentar el número de efectivos, en este caso duplicar el número de equipos. (Permíteme que no entre ahora mismo a discutir si es la mejor decisión o no). Sea como sea, ponte en la situación de que ahora tienes dos equipos trabajando en el mismo producto. El doble de coste de producción (ahora tendremos a dos equipos en vez de uno y vamos a suponer que son muy parecidos) se compensará porque podremos mantener el ritmo de trabajo y/o llegaremos a la fecha pactada.

Si somos cuidadosos en ese reparto del trabajo, ambos equipos podrán ser bastante independientes, salvo en dos puntos del proceso: el refinamiento y la integración.

2 equipos y 1 producto

El refinamiento, el desglose en funcionalidades, la coordinación, o la priorización de los planes, llámala como quieras, es esa fase previa a que cada equipo tenga ya sus planes asignados y los pueda manejar de manera independiente. Es muy importante recordar que todas aquellas dependencias que no gestiones en esta fase se convertirán en bloqueos para los equipos durante el desarrollo.

La integración es el proceso en el que los incrementos de producto que cada equipo ha desarrollado por separado se juntan en uno sólo, puesto que sólo tenemos un producto y nuestros usuarios lo reciben como tal. Ésta es una actividad que debemos tratarla también como un riesgo. Sin embargo, como apenas son dos equipos, normalmente lo que solemos hacer es apenas poner más atención de la que poníamos cuando sólo era un equipo; quizás unas pruebas de aceptación (UAT) más planificadas y con más gente involucrada porque sabemos que es más fácil que se nos pase algún detalle.

Considera el proceso de despliegue (o deployment) parte de lo que aquí estoy llamando integración porque no siempre es posible evitar esta dependencia entre equipos. El caso más obvio que se me ha dado son las apps para móviles, que hay que entregarlas como un único paquete en la tienda de turno (p.ej. la App Store) para que desde ahí ya se distribuya hasta los clientes.

Navegando la tensión de aumentar el número de equipos

3 equipos y 1 producto

Sigamos navegando esta tensión y aumentemos el número de equipos: pasamos de 2 equipos a 3.

Así, si observamos el proceso de refinamiento, la carga cognitiva de quien ejerce de responsable de producto (Product Owner) se resiente. ¿A cuántos equipos puede atender efectivamente? ¿A cuántas reuniones de refinamiento, planificación, etc puede asistir y aun así seguir atendiendo a los stakeholders del producto y dedicando tiempo de calidad a estudiar el feedback de los usuarios y a elaborar un estrategia de producto que responda al mismo? El tiempo disponible es una restricción ineludible y no suele terminar bien cuando tratamos de compensarla llevando trabajo a casa, trabajando mientras estamos en otra reunión, etc. Porque, tarde o temprano, la calidad de lo que hacemos se terminará resintiendo.

Por otro lado, las tareas de integración se vuelven aún más complicadas. La calidad del producto final pasa a ser una preocupación y, a las responsabilidades habituales del Product Owner, se le añadirá aún más exigencia para garantizar la calidad final. Esto suele provocar la contratación de especialistas en aseguramiento de la calidad (QA), pero no siempre lo hacemos de la manera correcta porque no estamos interpretando bien esta tensión.

Vamos a ver qué pasa cuando el número de equipos crece mucho más y entenderemos mejor qué está sucediendo realmente.

N equipos y 1 producto

Como ya hemos visto antes, a medida que aumenta el número de equipos, aumenta también la cantidad de tareas de refinamiento que debe hacer una única persona: el Product Owner. Se irá haciendo necesaria una estrategia para dividir ese rol (y el producto del cuál sea responsable) para repartirlo entre los diferentes equipos. Enseguida te propondré algunas estrategias para esto.

Algo equivalente sucede en el otro extremo del flujo de trabajo: la integración. A medida que aumenta el número de equipos, también aumenta la necesidad de sincronizar las entregas del único producto existente y el esfuerzo para garantizar la calidad del resultado final.

Criterios para repartir un producto en el que trabajan demasiados equipos

Los principales problemas que hemos visto navegando esta tensión son:

  • la necesidad de coordinar las peticiones de trabajo que les llegan a los equipos, que hemos llamado refinamiento, y que está limitado principalmente por la carga cognitiva que puede soportar un Product Owner, y el tiempo disponible para hacer su trabajo,
  • la necesidad de sincronizar las entregas de los incrementos de producto de cada equipo.

Si pudieramos repartir el desarrollo del único producto entre los diferentes equipos, con una independencia tal que pudieramos trabajar como en productos completamente independientes, estaríamos en el escenario ideal que describíamos en los primeros párrafos del artículo anterior.

Vamos a estudiar cómo podemos actuar en los diferentes elementos de nuestro sistema para favorecer esta independencia entre equipos:

El rol del Product Owner

Resulta evidente que, para reducir la carga cognitiva del único Product Owner de nuestro producto, necesitamos repartir ésta entre varios individuos. Así, tendremos que decidir qué partes del producto son responsabilidad de cada PO.

Como todo es un único producto, tendremos que asegurarnos de que exista un buen proceso de coordinación de los backlogs de los que se responsabilice cada PO. Y esa coordinación debe garantizarse desde el momento de la ideación, es decir, desde que surge una idea. Es imprescindible que exista un ambiente de colaboración para que las ideas se sumen y no se pisen o generen silos.

Como ya vimos en el artículo anterior, a veces podemos tener varios PO para un mismo equipo. Si combinamos esa solución con ésta, podemos llegar a la conclusión de que podemos tener una especie de “pool” de POs. Cuidado, porque pretender que un Product Owner es intercambiable simplemente porque sólo tenemos un producto es engañarnos, porque la carga cognitiva seguirá siendo prácticamente la misma, pues tendrá que conocer todos los detalles del producto, con el agravante de que, a medida que éste va creciendo, muchas de las funcionalidades habrán sido desarrolladas por otros compañeros y la necesidad de compartir este conocimiento irá en aumento, no siendo precisamente una tarea muy eficiente porque hay probabilidades de que nunca necesites trabajar en esas funcionalidades.

Los Product Backlog

Como ya he comentado anteriormente, el backlog lo solemos asociar a un equipo y a un Product Owner, pero esto es una restricción autoimpuesta. En este escenario, en el momento en el que dividimos el equipo original pero el producto sigue siendo único, el backlog de producto también es único. Sin embargo, cuando dividimos al Product Owner nos surge la oportunidad de dividir también el backlog y que cada Product Owner se lleve un trozo del backlog, con las reglas que hemos comentado antes. Esto favorece que vayamos tendiendo a una fórmula 1 PO ↔ 1 Backlog ↔ 1 Equipo.

Sin embargo, es imprescindible que coordinemos el reparto del trabajo. Por eso es recomendable tener un artefacto donde visualizarlo y hacerle seguimiento, por ejemplo con un tablero kanban, con el que de paso podremos gestionar el trabajo, incluyendo lo relacionado con la integración, y extraer métricas que nos ayuden a gestionar expectativas y a mejorar el propio proceso.

Los Incrementos de Producto

Una técnica muy frecuente para integrar los diferentes incrementos de producto de cada equipo es el “release train” (al cuál ya dediqué este artículo hace algún tiempo). En este escenario es normal que haya equipos más “rápidos” que otros, pero los usuarios siempre recibirán una única entrega, por lo que habrá funcionalidades ya terminadas que estarán esperando a las de los equipos más “lentos”.

Todo esto hace que nuestra eficiencia en la entrega de valor se vea mermada, pero recuerda que, a cambio, estamos entregando más software porque tenemos a más gente trabajando… o no. Recuerda: «9 mujeres no pueden tener un bebé en 1 mes». Como el trabajo que deben hacer los equipos no es totalmente independiente (porque necesitan coordinar el refinamiento y la integración), el tiempo total no disminuye. De hecho, como bien explica Brooks en “The Mythical Man-Month”, el tiempo total aumenta.

El Equipo de Desarrollo

A medida que aumenta el número de equipos, también surgen roles transversales para cuidar aspectos como la arquitectura, las buenas prácticas, etc. Sobre todo si el origen de ese aumento de equipos es el aumento de la complejidad del producto, porque se hace necesario garantizar una homogeneidad en los criterios del diseño interno, que a su vez garantice la mantenibilidad y minimice el impacto de una posible rotación de personal. Hay que tener mucho cuidado con esto porque, llevado al extremo, esto genera un entorno de trabajo en el que terminamos gestionando recursos en vez de colaborando con personas.

El Feedback de los Usuarios

Hace tiempo escribí aquí sobre cómo recogemos el feedback de los usuarios y lo incorporamos para la mejora del producto. En este escenario, con múltiples equipos pero con un único producto, los usuarios no tienen por qué saber qué equipo es responsable de resolver un defecto o incorporar una mejora, es más, hay defectos o mejoras que muchas veces no se corresponden con un único equipo. De hecho, justamente ése es el mayor reto: repartir el trozo de producto del que cada equipo es responsable para minimizar el tiempo a dedicar en la coordinación del reparto y de la integración.

¿Cómo minimizar este riesgo? Fundamentalmente hay dos maneras: minimizar las dependencias por diseño, y automatizar las tareas de integración. La primera minimiza la cantidad de trabajo a hacer, la segunda minimiza la cantidad de errores humanos y garantiza la calidad y predictibilidad de nuestro producto. Y de nuevo insistiré en el uso de un tablero kanban del que podremos extraer métricas con las que mejoraremos nuestro sistema.

Resumen de cómo escalar cuando crece el número de equipos

En el artículo anterior llegamos a la conclusión de que, cuando aumentamos el número de productos/proyectos, el límite está en la capacidad de los roles responsables de producto y los equipos para enfocarse en hacer su trabajo. Pero cuando aumentamos el número de equipos, el límite pasa a estar en la autonomía de los mismos. A mayor independencia, menos esfuerzo de coordinación tanto en el refinamiento de producto como en la integración.

Resumen: N equipos y 1 producto

Recuerda: «9 mujeres embarazadas no pueden tener un bebé en 1 mes».

  • Divide tu producto en otros sub-productos independientes.
  • “Scrum de scrums” (u otras prácticas similares) mejoran la comunicación / coordinación entre equipos.
  • Los “release trains” permiten sincronizar a todos los equipos, aunque puede ralentizar toda la cadena de producción.
  • Automatiza las integraciones.

LA FOTO: .

Creo que una pizza puede ser una buena metáfora para el tema de hoy porque nos permite lanzar conversaciones muy interesantes. ¿Es una única pizza aquella que dividimos estrictamente en dos partes? Bueno, pues sí, porque la entregamos al cliente en la misma caja. ¿Y qué pasa cuando somos 12 amigos? Quizás necesitemos más de una pizza, es más, eso nos lleva a que nos pondremos de acuerdo en los ingredientes de otra manera. Ya sé, es que me gustan mucho las metáforas.

Foto de Klara Kulikova en Unsplash

  1. En realidad, en el segundo capítulo de “The Mythical Man-Month” que da título al libro, Brooks escribe «Un embarazo dura 9 meses, no importa cuántas mujeres dediques a ello». Sin embargo, lo más frecuente es encontrarla parafraseada como «9 mujeres no dan a luz un niño en 1 mes», fórmula que, según parece, es original de Theodore von Kármán: «Todo el mundo sabe que una mujer tarda nueve meses en tener un bebé. Pero ustedes, los estadounidenses, piensan que si embarazan a nueve mujeres, pueden tener un bebé en un mes».