El proceso que funcionaba con 15 desarrolladores se rompe con 50

Un equipo con el que trabajé creció de un puñado de desarrolladores a quince sin agregar ni una sola ceremonia. Cuatro eventos, los mismos cuatro con los que habían arrancado, timeboxes fijos en todo momento. Esa disciplina hizo más trabajo del que parecía en su momento.

Hacer crecer un equipo sin hacer crecer su sobrecarga de coordinación es un desafío. La cantidad de canales de comunicación en un grupo crece de forma combinatoria con la cantidad de gente — la observación original de Fred Brooks, resumida normalmente como n(n-1)/2 — así que duplicar un equipo no duplica la carga de coordinación, la multiplica varias veces. La mayoría de los equipos sienten esa aritmética directamente: más reuniones, dailies más largas, decisiones que antes tomaban una hora y ahora tardan un día.

Este equipo no lo sintió, porque se había adelantado. Las cuatro ceremonias se mantuvieron fijas, pero lo que pasaba adentro cambió — los criterios de aceptación se volvieron más explícitos, los acuerdos de trabajo se hicieron más pesados, la definición de terminado se ajustó a medida que crecía la cantidad de gente. La disciplina absorbió el costo combinatorio antes de que pudiera aparecer como una traba visible en la entrega.

Años después, el CTO de ese proyecto me invitó a tomar un café. El equipo ahora tenia 50 programadores, organisado en tres sub-equipos. La entrega a producción era más frecuente, y de mayor volumen, que nunca. Y sin embargo, según me contó, el equipo nunca había vuelto a sentirse tan productivo como el año en en que tuvieron que dividir en equipo original para seguir creciendo.

Lo que estaba describiendo, hasta donde puedo interpretar de su relato, tiene un nombre distinto del problema que había resuelto con quince personas. La ley de Conway sostiene que las organizaciones diseñan sistemas que reflejan su propia estructura de comunicación. Una vez que un equipo se divide, los límites entre los equipos nuevos dejan de ser una cuestión interna de ceremonias y pasan a ser una cuestión estructural: ¿esos límites realmente coinciden con las costuras del software, o se trazaron según lo que era administrativamente conveniente en su momento? Cuando no coinciden, cada dependencia entre equipos se convierte en un problema de sincronización, y ninguna disciplina interna lo resuelve, porque el costo de coordinación no desapareció — se mudó a un límite que nadie, dentro de ninguno de los dos equipos, tiene a su cargo.

Esa es una lectura plausible de por qué la sensación de productividad bajó aunque las métricas mejoraron. El volumen y la frecuencia se ven a nivel de equipo. La fricción que describía vive entre equipos, en mediciones inconsistentes y sincronización no planificada — justo la capa que un dashboard por equipo está construido para no ver.

Los dos problemas no comparten solución. Un problema de la ley de Brooks se absorbe ajustando lo que un equipo acuerda puertas adentro. Un problema de la ley de Conway plantea una pregunta distinta por completo: quién es realmente dueño del límite entre dos equipos, y quién decidió dónde iba a estar trazada esa línea en primer lugar.

El punto de apalancamiento es distinto para cada equipo. Encontrarlo es el trabajo.