Un gráfico de velocidad cae dos sprints seguidos, y un CTO lo lee como una caída — el número exacto que un board te va a preguntar directamente. A veces esa lectura es correcta; no toda caída significa algo. Más seguido, encuentro, el gráfico está reportando otra cosa: no menos trabajo hecho, sino un desacuerdo sobre qué cuenta como terminado.
Esa ambigüedad es fácil de pasar por alto porque todos asumen que hay acuerdo. “Terminado” se siente evidente hasta que se pone a prueba contra un ticket real. ¿Terminado significa:
- que el código se mergea?
- que está testeado?
- que lo revisó un segundo desarrollador?
- que está deployado?
- que estuvo un día en monitoreo sin incidentes?
- que está documentado lo suficiente como para que otra persona lo pueda retomar en seis meses?
Mi guía gratuita — Perspectivas para la Mejora — explica cómo identificar las brechas de calidad y construir los hábitos de equipo que las cierran. Utilizada por equipos ágiles en LATAM y España.
Descárgala gratis →
Cada una de estas es una línea razonable para trazar, y distintas personas del mismo equipo la están trazando en distintos lugares.
Noto esto más marcado en equipos que crecieron rápido después de una ronda de inversión. Ingenieros nuevos llegan de empresas con estándares distintos — para uno, “revisado” es una mirada rápida de cortesía; para otro, es un filtro duro. Ninguno de los dos lo escribió, así que la brecha no aparece hasta que un ticket se reabre a mitad de sprint y dos personas descubren, en medio de una discusión, que nunca operaron con la misma definición.
Vale la pena detenerse en esa reapertura. Un equipo estima el trabajo de un sprint, cierra la mayoría, y después un tercio de esos tickets “terminados” vuelven — reabiertos contra un criterio que nadie había nombrado como requisito hasta que alguien lo aplicó después del hecho. Y a medida que esto se acumula, las métricas de velocidad empiezan a verse mal.
Ahí también suele vivir la tensión entre deuda técnica y features. Una feature “terminada” que se saltó el monitoreo o dejó un atajo en la capa de datos no es una decisión de deuda que alguien tomó conscientemente — es una definición que se fue angostando en silencio bajo presión de tiempo.
La respuesta obvia es agregar una reunión: una revisión de historias completadas antes de la reunión de revisión, agendada y con alguien a cargo, tratando la brecha como un problema de proceso para resolver con calendario. Rara vez ahí está la palanca. Lo que suele funcionar es la estandarización: o sea, nombrar, para cada tipo de trabajo, qué tiene que ser cierto específicamente para que cuente como terminado, y quién es responsable de verificarlo.
Una vez que eso es visible, la conversación sobre velocidad cambia de forma. Un board que pregunta por qué se frenó la entrega recibe una respuesta más útil que “el equipo está en eso” — recibe un relato específico de qué cambió en lo que cuenta como completo, y por qué.
El punto de apalancamiento es distinto para cada equipo. Encontrarlo es el trabajo.
Una guía práctica para convertir la mejora del equipo en un sistema repetible — el mismo enfoque que uso con mis clientes. Sin ventas, solo el marco de trabajo.
Descargar: Perspectivas para la Mejora →
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
