Dos equipos, un monolito y una Sprint de endurecimiento cada cuatro
Dos equipos Scrum, Checkout y Pagos, trabajan sobre el mismo monolito Java. Cada uno tiene su Product Backlog y su propia Definition of Done. La integración se hace al final de cada Sprint de cuatro semanas, en una «Sprint de endurecimiento» en la que nadie desarrolla funcionalidad. El año pasado se dedicaron 9 de 48 semanas a esas Sprints de estabilización. En el PI planning trimestral se identifican dependencias, pero el 70% de ellas cambia antes de la semana 5. Las pruebas end-to-end las ejecuta un equipo de QA separado, que recibe builds cada tres semanas y devuelve informes con 60-90 defectos. La dirección ha fijado como prioridad la «velocidad» y ha puesto un objetivo de 15 historias por equipo y Sprint. La moral está baja: dos personas rotaron el trimestre pasado y QA tiene tres vacantes sin cubrir.
1. ¿Cuáles son las causas estructurales del problema y en qué orden las atacarías?
Read the worked answer
Diagnóstico. El 19% de la capacidad anual (9 de 48 semanas) se dedica a integrar lo que nunca se integró antes. Eso no es un problema de planificación: es deuda de integración acumulada por el diseño organizativo.
Causas encadenadas:
- Equipos por componente sobre un monolito único. Checkout y Pagos no pueden entregar valor de forma independiente; cualquier funcionalidad cruza el límite. De ahí que el 70% de las dependencias cambie: no es mala previsión, es que las dependencias son estructurales y no se pueden enumerar de antemano.
- Dos Definition of Done y una sola integración al final del Sprint. Cada equipo declara «terminado» algo que no está integrado. El hardening es el síntoma que paga la factura.
- QA como equipo separado con builds cada tres semanas. El lote de cambios es enorme y el feedback llega cuando el autor ya no recuerda el código: 60-90 defectos por ciclo es exactamente lo esperable.
Orden de ataque: primero la Definition of Done compartida y la integración continua diaria (barato, efecto inmediato); después reducir el tamaño de lote bajando a Sprints de dos semanas; después disolver la separación de QA incorporando capacidad de prueba a los equipos; por último, el rediseño de límites de equipo o arquitectura, que es el cambio más lento.
No empezar por el organigrama: sin integración continua, cualquier reorganización reproduce el mismo problema con otros nombres.
2. La dirección ha fijado 15 historias por equipo y Sprint como objetivo de velocidad. ¿Qué mides en su lugar y por qué ese objetivo es contraproducente?
Read the worked answer
Por qué es contraproducente. «Historia» no es una unidad comparable: un equipo puede partir una historia en cinco y otro en una. Un objetivo de 15 historias por equipo premia dividir el trabajo en trozos pequeños, no entregar más valor. Es el ejemplo clásico de métrica convertida en objetivo: se optimiza el número y se degrada lo que el número pretendía representar.
Qué medir en su lugar:
- Tiempo de ciclo desde el primer commit hasta producción: captura el efecto real de la integración y del tamaño de lote.
- Throughput por resultado, no por historia: elementos que cumplen la Definition of Done compartida.
- Porcentaje de capacidad dedicada a trabajo no planificado (defectos, estabilización): si baja del 20% al 8%, el mensaje es inequívoco.
- Defectos escapados a producción y tiempo medio de restauración.
- Frecuencia de integración: builds verdes por día.
Cómo presentarlo a dirección sin sonar defensivo: llevar la evidencia de las 9 semanas de hardening y traducirla a coste. «Cada semana de estabilización cuesta X; el objetivo de 15 historias no reduce ese coste, lo esconde». Proponer un piloto de un trimestre con dos o tres métricas y revisión conjunta.
Advertencia que hay que dejar por escrito: si estas métricas se usan después para comparar equipos o evaluar personas, se corromperán igual que el conteo de historias.
3. Un director propone crear el rol de «coordinador de dependencias» entre Checkout y Pagos. Evalúa la propuesta y ofrece una alternativa.
Read the worked answer
Qué resuelve de verdad. Un coordinador puede reducir el ruido a corto plazo: alguien que mantiene el mapa de dependencias y avisa. Es una medida barata y no hay que descartarla de entrada.
Qué no resuelve. La dependencia es arquitectónica y organizativa. Un rol que la gestiona la hace más cómoda de mantener: si el dolor desaparece de la vista de los directivos, la causa raíz deja de tener urgencia. Además, el coordinador se convierte en un nuevo cuello de botella y en un punto único de conocimiento, justo lo que el caso ya sufre con QA.
Alternativa, en tres piezas:
- Objetivo de producto compartido por ambos equipos, con una única lista priorizada de resultados y una Definition of Done común. Sin esto, ninguna coordinación funciona.
- Prácticas conjuntas de ingeniería: integración continua diaria, revisión de código cruzada y sesiones conjuntas de refinamiento técnico de las historias que cruzan el límite. Un 20-30% del refinamiento debería ser conjunto.
- Reducción estructural de la dependencia: identificar los dos o tres puntos del monolito por donde pasan la mayoría de los cruces y planificar trabajo de arquitectura para separarlos. Es lento, pero es la única salida que no se reproduce.
Si se crea el rol, que sea temporal y con criterio de salida: por ejemplo, tres meses con el objetivo explícito de que el número de dependencias que requieren coordinación manual baje de un umbral acordado. Y que no sustituya al objetivo compartido ni a la Definition of Done única.