Parte III. El Sprint con IA
El Sprint dura lo que tarda en volver la respuesta
Duración del Sprint, Sprints cortos y los relojes humanos
Sprints de tres días
Cuando Ramón vio que el equipo construía en una tarde lo que antes era un Sprint, propuso lo que parecía lógico: si el trabajo va más rápido, que el Sprint también. GymApp pasó de Sprints de dos semanas a Sprints de tres días.
Duró dos Sprints. En la segunda Review, Héctor enseñó catorce entregas: el aviso de plazas en el calendario, mejoras en la lista de espera, un filtro nuevo. Begoña preguntó si la lista de espera estaba sirviendo para que los socios nuevos reservaran más. Nadie lo sabía. La medida que habían acordado, las reservas de cada socio nuevo en su primer mes, necesitaba como poco un mes.
Olga hizo otra cuenta. En seis días de trabajo, el equipo había pasado casi uno entero en eventos de Scrum. Celia no había podido citar a ningún socio para una entrevista, porque encontrar cinco personas dispuestas le llevaba más de tres días. Y Germán dijo lo que pensaban todos: tenían la sensación de estar siempre empezando.
Entregar no es lo mismo que cerrar un Sprint
La propuesta de Ramón mezclaba dos ritmos que con IA se han separado.
Uno es el ritmo de entregar: cada cuánto llega algo nuevo a producción. Con agentes, integración continua y despliegue automático, puede ser varias veces al día, y eso está bien.
El otro es el ritmo de aprender y decidir: cada cuánto sabe el equipo lo suficiente para cambiar de rumbo. Ese ritmo no depende de lo rápido que se construye, sino de lo rápido que vuelve la respuesta: la de los usuarios, la de los datos y la de las personas que tienen que decidir. Es el que marca el Sprint. El Sprint dura lo que tarda en volver la respuesta, no lo que tarda en escribirse el código.
La Guía Scrum ya separa las dos cosas. Un Sprint dura un mes o menos, y los Sprints más cortos sirven para tener más ciclos de aprendizaje y limitar el riesgo. Pero un incremento no tiene que esperar al final del Sprint para salir: puede entregarse en cuanto cumple la Definition of Done, y en un Sprint caben varios. Con agentes, lo normal es entregar muchas veces dentro de cada Sprint.
Los relojes que la IA no acelera
La respuesta vuelve a ritmo humano. Hay tres relojes que la IA casi no acelera.
El de quien revisa y decide. Revisar bien exige atención, y la atención se agota: revisar cansa más que escribir (capítulo 8). Decidir también. Nuestros tres agentes me piden entre quince y veinticinco decisiones a la semana, y no podría tomar bien el doble. Por mucho que generen los agentes, el equipo avanza al ritmo al que sus personas pueden revisar y decidir con criterio.
El del usuario. Encontrar cinco personas para una entrevista lleva días. Ver si un cambio modifica un hábito lleva semanas. Y quien usa el producto también tiene su límite: una app que cambia cada tres días cansa (es el coste cognitivo del capítulo 11).
El de la organización. Una aprobación, una revisión legal, formar a quien va a usar el sistema (capítulo 16). Llevan su tiempo, y casi nunca es el del equipo.
Con IA, el cuello de botella no es la máquina: son estos tres relojes. Por eso validar es agotador, porque las personas revisan al ritmo al que la máquina genera. Y por eso descubrir y medir no van a la velocidad de la máquina.
Depende de tu contexto
No hay una duración buena para todos. Depende de dónde está tu producto y de cuánto tardas en saber si algo funciona.
Un producto nuevo, todavía con pocos usuarios, aprende sobre todo de prototipos y conversaciones. La respuesta puede volver en días. Ahí suele funcionar bien un Sprint de una semana con entregas diarias.
Un producto maduro, con muchos usuarios y hábitos asentados, aprende sobre todo de cómo cambia el comportamiento. Un experimento A/B necesita tráfico suficiente y semanas completas, porque el lunes no se comporta como el sábado; lo explican Ron Kohavi, Diane Tang y Ya Xu en Trustworthy Online Controlled Experiments (Cambridge University Press, 2020).
Ahí lo habitual es un Sprint de dos semanas, también con entregas frecuentes dentro.
Y en un entorno regulado o con mucho riesgo, las aprobaciones marcan el ritmo y conviene no ir por delante de ellas (capítulo 20).
Acortar cuando las restricciones lo permitan
Lo que sí se puede hacer es ir acortando. Se empieza con un Sprint de una o dos semanas, según el contexto, y se acorta cuando las restricciones lo permiten: cuando la evidencia llega antes de la Review, cuando el equipo revisa lo que genera sin que se acumule, cuando las personas que deciden pueden venir y cuando los eventos ocupan poco del tiempo del Sprint.
Las señales para alargarlo son las contrarias: Reviews sin evidencia, Sprint Goals que son listas de entregas, un equipo que vive planificando y personas interesadas que dejan de venir.
Un Sprint de tres días puede ser un destino. Hay equipos que llegan ahí, con un producto que da respuesta en horas, usuarios a mano y una red de seguridad muy buena. Pero es una consecuencia de su meta y de su contexto, nunca un objetivo en sí mismo. Si acortas el Sprint porque construir ya es rápido, acortas el sitio donde el equipo decide, no el tiempo que tarda en saber.
Cuando la evidencia llega después del Sprint
Aun con Sprints de dos semanas, mucha evidencia llega tarde. Las reservas del primer mes de un socio no se ven en catorce días. No es un problema si el equipo lo sabe y se organiza para ello.
Señales adelantadas y medidas de resultado. Las medidas de resultado (retención, ingresos, reservas en el primer mes) llegan semanas después.
Las señales adelantadas llegan en días: unas pruebas con cinco usuarios, que bastan para encontrar la mayoría de los problemas de uso, como explicó Jakob Nielsen en 2000; el primer uso; si la gente completa la tarea; los errores y las quejas. Cada apuesta del Sprint lleva las dos, y la fecha en que llegará la medida de resultado.
Una Review en dos partes. La primera, lo que entregamos en este Sprint y lo que ya sabemos de ello. La segunda, lo que dicen ahora los datos de lo que entregamos hace tres o seis semanas. Para no perderlo, un registro de apuestas: qué se entregó, qué se esperaba y cuándo se podrá medir.
Saber qué movió la medida. Con agentes salen tantos cambios que es difícil saber cuál movió una cifra. Ayuda apuntar cada cambio con su fecha, no tocar a la vez dos cosas que afectan a la misma medida, probar con un grupo de usuarios antes que con todos y, a veces, dejar quieto lo que se está midiendo.
Eso último lo hicimos en nuestra web este otoño. Habíamos cambiado en pocos días muchas páginas para atraer más visitas y más altas. Antes de mirar los datos fijamos qué contaría como éxito, programamos lecturas a una, dos, tres y cuatro semanas, y otra a ocho para lo que tarda más en notarse en los buscadores.
Y durante cuatro semanas no tocamos lo que estábamos midiendo, para poder atribuir lo que se moviera. Los cambios salieron en pocos días. La respuesta tarda un mes, y la de los buscadores, dos.
Lo que hizo GymApp
GymApp no volvió a las dos semanas: pasó a Sprints de una semana. Con Celia y Héctor hablando con socios cada semana, la respuesta de los prototipos llegaba a tiempo para la Review. Siguieron entregando a diario. Y la Review pasó a tener dos partes; en la segunda, a las cuatro semanas, apareció por fin el dato de la lista de espera.
Ramón preguntó si algún día volverían a los tres días. Olga contestó que quizá, cuando la respuesta llegara en tres días.
En resumen
El Sprint dura lo que tarda en volver la respuesta, y la respuesta vuelve a ritmo humano: el de quien revisa y decide, el del usuario y el de la organización. Entrega tan a menudo como puedas, elige la duración del Sprint según tu contexto (una o dos semanas para empezar) y acórtala solo cuando las restricciones lo permitan. Tres días pueden ser un destino, nunca un objetivo.
Y como mucha evidencia llega después del Sprint, la Review mira también lo que entregaste hace semanas.
Pruébalo esta semana
Para cada elemento del Sprint, apunta cuándo llegará la evidencia de que ha servido: la señal adelantada y la medida de resultado. Si casi todo llega después de la Review, acortar el Sprint no te dará más información. Si llega casi todo antes, prueba a acortarlo durante tres Sprints y mide con el cuadro del capítulo 17.