Parte II. El equipo: personas y agentes
Menos personas, no menos criterio
El tamaño del equipo cuando hay agentes
¿Me sobran tres?
En la revisión del presupuesto, Ramón hizo la cuenta que estaban haciendo muchos directores de tecnología ese año. GymApp tenía seis personas y entregaba el doble que antes de usar agentes. ¿No bastaría con tres?
Olga no contestó con una opinión. Propuso apuntar, durante dos Sprints, en qué se iban las horas del equipo. El resultado sorprendió a Ramón. Escribir código, que era lo que habían abaratado los agentes, ocupaba menos de una quinta parte del tiempo.
El resto se iba en revisar lo que generaban los agentes, en hablar con socios, en decidir qué entraba y en coordinarse con otros equipos. Y había algo que la cuenta no recogía: la semana que Germán estuvo de baja, nadie más supo revisar los cambios en pagos.
Ramón no quitó a nadie. Tampoco dejó el equipo como estaba.
El tamaño ya no lo marca escribir código
La Guía Scrum dice que un equipo Scrum tiene normalmente diez personas o menos: lo bastante pequeño para moverse rápido y lo bastante grande para terminar un trabajo importante en un Sprint. Durante años, la mayoría de los equipos se han movido entre cinco y nueve personas, porque hacía falta gente para construir.
Con agentes, construir necesita menos personas. Pero los agentes no son miembros del equipo (capítulo 5) y no reducen todo el trabajo por igual. Reducen mucho el de escribir. Reducen poco el de revisar, descubrir, decidir y coordinar, que son justo los relojes humanos del capítulo 12. El tamaño de un equipo con agentes lo marca su capacidad de revisar y decidir, no la de construir.
De qué depende cuánto se puede reducir
No hay una cifra que sirva para todos. Hay seis factores que conviene mirar antes de decidir:
- La capacidad de revisión. Cuántos cambios generan los agentes por semana y cuántas horas de revisión con calidad tiene el equipo. Si generan más de lo que se puede revisar, sobran agentes; no faltan personas que aprueben más deprisa.
- El criterio que hace falta. Cada riesgo que el equipo lleva a producción necesita a alguien que sepa juzgarlo: producto, diseño, pruebas, seguridad, datos, el negocio. Una persona con agentes cubre más áreas que antes, pero en cada una alguien tiene que saber cuándo lo que propone un agente está mal.
- La continuidad. Vacaciones, bajas, alguien que se va. Si solo una persona sabe revisar los pagos, el equipo es tan grande como esa persona.
- El riesgo del producto. Una app con pagos, datos de salud o menores necesita más ojos que una herramienta interna.
- El descubrimiento. Hablar con usuarios, preparar pruebas y entender lo que pasa lleva horas de personas, y los agentes lo acortan poco (capítulo 10).
- La red de seguridad. Specs, pruebas automáticas, una Definition of Done exigente y agentes que comprueban cada noche. Cuanto mejor es la red, menos revisión humana necesita cada cambio, y más se puede reducir.
Con todo eso, mi punto de partida hoy para un producto que se usa de verdad es un equipo de tres a cinco personas, cada una trabajando con sus agentes. Por debajo de tres, casi siempre falla la continuidad o falta el segundo par de ojos.
Equipos grandes, equipos pequeños
Las dinámicas cambian con el tamaño, y con agentes cambian más.
En un equipo grande con agentes, de siete a nueve personas, cada una multiplica sus cambios y todas tocan el mismo producto. Los canales de comunicación crecen deprisa: con n personas hay n × (n - 1) / 2 parejas que tienen que entenderse, 21 con siete personas y 36 con nueve.
Es la cuenta que hizo famosa Fred Brooks en The Mythical Man-Month (1975), y con agentes cada canal lleva más cambios. Aparecen los choques entre cambios, la cola de revisión delante de dos o tres personas (capítulo 4) y la tentación de partirse en subgrupos que no se hablan. Si un equipo crece hasta ahí, suele ser mejor partirlo en dos alrededor del flujo de valor (capítulo 18).
En un equipo pequeño con agentes, de tres a cinco personas, hay menos canales, de 3 a 10, y las decisiones son más rápidas. El riesgo cambia de sitio: cada persona dirige a varios agentes y se convierte en la revisora de todo lo que generan. Si nadie lo vigila, aparecen el cansancio de verificar y la calidad que solo parece buena.
En un equipo pequeño, el acuerdo de trabajo del capítulo 6 y los límites de revisión no son opcionales.
Y está el caso extremo, una persona con agentes. Es el de nuestra web: yo, con tres agentes que trabajan cada día. Funciona para un producto pequeño, y tiene dos límites que conozco bien. Todas las decisiones pasan por una persona, así que mi atención es el cuello de botella.
Y no hay un segundo par de ojos: los agentes comprueban mucho, pero cuando lo medimos, la mayoría de los fallos los encontraba yo (capítulo 5). No lo recomendaría para un producto del que dependen miles de usuarios.
Más agentes no es mejor equipo
Dentro del equipo pasa algo parecido con el número de agentes. Hasta cierto punto, más agentes significa más capacidad. A partir de ahí, la persona que los dirige deja de revisar y empieza a aprobar. Hay tres señales de que un equipo tiene más agentes de los que puede llevar:
- La cola de revisión crece Sprint a Sprint.
- Sube el trabajo que hay que rehacer después de integrarlo.
- Alguien dice "lo he aprobado, pero no lo he leído entero".
Cuando aparecen, la solución no es poner más personas a aprobar. Es lanzar menos trabajo a la vez, hacer cambios más pequeños o mejorar la red de seguridad.
Hay otra consecuencia: en un equipo con agentes, cada persona necesita más capacidades. Pesan más el criterio de producto, las pruebas, el diseño y la seguridad. En Team Topologies (2019), Matthew Skelton y Manuel Pais lo llaman carga cognitiva: un equipo no puede ser dueño de más producto del que es capaz de entender. Con agentes, el equipo construye más deprisa y ese límite llega antes.
Cómo calcularlo en tu equipo
Antes de quitar o añadir a nadie, mide dos Sprints:
- Cuántos cambios generan los agentes por semana y cuánta revisión necesita cada uno.
- Cuántas horas tiene el equipo para revisar con calidad, sin pasar de cuatro al día por persona.
- Cuántas horas van a descubrir, decidir y coordinar.
- Qué áreas de riesgo solo sabe revisar una persona.
Si la revisión necesaria supera a la disponible, el problema no se arregla quitando personas. Si sobra capacidad de revisión y ninguna área depende de una sola persona, el equipo puede ser más pequeño, o puede asumir más producto.
GymApp se quedó con sus seis personas, pero con otro reparto: menos horas de escribir y más de revisar y de hablar con socios. Germán enseñó a Aitana a revisar los cambios en pagos. Y la siguiente persona que contrató GymTonic no fue a GymApp: fue al segundo equipo, el de reservas y pagos (capítulo 18).
En resumen
Con agentes hacen falta menos personas para construir, pero no para revisar, descubrir y decidir. El tamaño lo marcan esas capacidades, la continuidad y el riesgo del producto. De tres a cinco personas es un buen punto de partida para un producto real; por debajo de tres falta el segundo par de ojos, y más agentes no compensan menos criterio.
Pruébalo esta semana
Durante un Sprint, apunta en qué se van las horas del equipo: escribir, revisar, descubrir, decidir y coordinar. Y haz la lista de las áreas que solo sabe revisar una persona. Las dos cosas juntas dicen si tu equipo puede ser más pequeño, y qué tendría que pasar antes.
Para diseñar el equipo y sus acuerdos desde cero tienes el Team Canvas.