Parte II. El equipo: personas y agentes
El Scrum Master no tiene que dominar la IA: tiene que ver qué le hace al equipo
Autogestión y alto rendimiento con IA
Dos personas que lo revisan todo
En la Retrospectiva de GymApp, Olga, la Scrum Master, pidió a cada uno que contara cuánto tiempo dedicaba a la semana a revisar código que no había escrito. Germán dijo que casi la mitad de su semana. Unai dijo que también. Aitana, que había entrado hacía dos meses, dijo que casi nada, porque lo que ella generaba con la IA lo revisaban ellos.
Nadie lo había decidido. Había pasado. Desde que el equipo usaba la IA para escribir código, los dos más veteranos se habían convertido en el filtro de todo, y estaban agotados. El equipo entregaba más que nunca y Germán llevaba tres semanas sin tocar la arquitectura de reservas, que era lo que más le preocupaba.
Olga no sabía programar con IA mejor que ellos. Pero era la única que estaba mirando cómo trabajaba el equipo, y no solo qué entregaba.
El trabajo de siempre, mirando a otro sitio
El Scrum Master sigue haciendo lo mismo que antes: ayudar al equipo a autogestionarse y a rendir alto. Autogestionarse significa que el equipo decide cómo trabaja. Rendir alto significa que aprende rápido, entrega con calidad y sabe por qué hace lo que hace.
Con IA, lo que cambia es dónde mirar. Un equipo no puede autogestionarse si no ve cómo está trabajando, y la IA cambia la forma de trabajar sin que nadie lo decida. Cada persona la usa a su manera, para cosas distintas y con resultados distintos, y eso no aparece en ningún tablero.
Tres cosas que el equipo tiene que ver
El trabajo del Scrum Master con IA es que el equipo sea consciente de tres cosas.
Cómo domina la IA. Quién la usa, para qué y con qué resultado. No se trata de vigilar, sino de que el equipo sepa qué funciona y qué no. Cuando alguien descubre una forma de pedir algo que ahorra una hora al día, eso es conocimiento del equipo, no un truco privado.
Cómo se organiza con ella. Quién revisa qué, cuándo entra un agente, qué trabajo no se le da nunca, qué pasa con lo que genera. Son acuerdos de trabajo, como lo son la Definition of Done o el límite de trabajo en curso. Si no se escriben, se forman solos, y suelen formarse mal.
Qué problemas le trae. Los que más se repiten:
- Dependencia: el equipo deja de saber hacer cosas que antes sabía.
- Revisiones que se acumulan delante de dos o tres personas, como en GymApp.
- Calidad que solo parece buena: código o documentos impecables por fuera que nadie ha comprobado.
- El cansancio de verificar todo el día, que cansa más que escribir.
- Conocimiento concentrado en quien mejor sabe pedirle las cosas a la IA.
- Distancia entre quien la usa mucho y quien no la usa, que acaba en dos velocidades dentro del mismo equipo.
No hace falta ser experto
El Scrum Master no tiene que ser experto en IA, igual que nunca tuvo que ser el mejor programador del equipo. Tiene que entender cómo afecta la IA al flujo, a la calidad y a las personas, y hacer las preguntas que nadie hace porque todos están ocupados entregando.
Sus herramientas son las de siempre, apuntadas a la IA:
- Preguntas en la Retrospectiva. Las tres de arriba, una cada Sprint si hace falta.
- Datos del flujo. Cuánto espera el trabajo antes de la revisión, cuánto vuelve atrás, quién revisa qué. Con eso, lo de Germán y Unai se habría visto un mes antes.
- Acuerdos de trabajo escritos. Una página, revisada cada pocos Sprints.
- Experimentos de un Sprint. Probar un cambio, medirlo y decidir si se queda.
También fuera del equipo
Hay un riesgo que viene de fuera: que la organización empiece a medir a la gente por cuánto usa la IA. Número de consultas, horas ahorradas declaradas, porcentaje de código generado. Son medidas fáciles de inflar y no dicen nada del valor. El Scrum Master también ayuda a la dirección a no caer en eso, y el capítulo 14 da alternativas.
En GymApp, el acuerdo que salió de aquella Retrospectiva cabía en cinco líneas: quien genera, revisa primero lo suyo; las revisiones se reparten entre todos; nadie revisa más de cuatro horas al día; los cambios grandes se dividen antes de pedir revisión; y cada dos Sprints se mira cómo va. Aitana fue la primera en pedir revisar el código de los demás.
En resumen
Autogestionarse con IA exige ver cómo se usa. El Scrum Master hace visibles tres cosas: cómo domina el equipo la IA, cómo se organiza con ella y qué problemas le trae. No necesita ser experto; necesita mirar donde nadie mira.
Pruébalo esta semana
Lleva estas tres preguntas a tu próxima Retrospectiva: ¿cómo estamos usando la IA?, ¿cómo nos organizamos con ella?, ¿qué problemas nos está trayendo? Escribe en una página el acuerdo que salga y fija la fecha en la que lo revisaréis.
Si buscas ideas para usar la IA en la propia Retrospectiva sin perder el criterio del equipo, las tienes en IA en retrospectivas, refinamiento y métricas.