De 40% a 92% de cumplimiento de sprint en 8 semanas.
Caso: VittaSami — producto propio del portfolio ABP Studio, SaaS clínico LATAM. Cómo, en una etapa temprana del producto, pasamos de incumplir cada sprint a entregar predeciblemente — sin contratar un solo developer nuevo. Hicimos esto en lo nuestro. Podemos hacerlo en tu equipo también.
La situación
VittaSami es nuestro SaaS clínico para LATAM — gestión de citas, pacientes y operación para clínicas y spas. En una etapa temprana del producto el delivery se había colapsado. El equipo consistentemente incumplía sus compromisos de sprint — completaba sólo el 40% de lo que planeaba cada dos semanas.
El roadmap estaba 4 meses atrasado. Dos ingenieros senior habían empezado a evaluar otros lados en silencio. Más tiempo se iba en escribir reportes de status y pedir disculpas por retrasos que en liderar al equipo y entregar producto.
No necesitábamos más developers. Necesitábamos un sistema de delivery que funcionara. Así que aplicamos en VittaSami el mismo playbook que hoy le vendemos al mercado.
Lo que encontramos
Pasamos los primeros 3 días hablando con cada miembro del equipo de forma individual y revisando 6 meses de data del proyecto. Los problemas se hicieron claros rápido.
/ 1. Planificación irreal
El equipo se comprometía a 20+ items por sprint en función de lo que pedía el roadmap comercial, no de lo que realmente podía entregar. No había data histórica para anclar la conversación. Los plannings eran sesiones de negociación donde el roadmap presionaba por más y el equipo aceptaba a regañadientes.
/ 2. Bloqueos invisibles
En promedio, 4 a 5 items por sprint estaban bloqueados 3+ días sin que nadie supiera. Los devs se movían a otras tareas en silencio cuando golpeaban una pared, y nadie trackeaba qué items estaban atascados ni por qué. Cuando los bloqueos aparecían, ya era tarde para recuperar el sprint.
/ 3. El trabajo no planificado dominaba
Casi la mitad de la capacidad del equipo se consumía en bug fixes urgentes, escalamientos de tenants piloto y “pedidos rápidos” del lado comercial. Nada de esto se contemplaba en planning. El equipo planificaba como si tuviera 100% de capacidad cuando en realidad tenía la mitad disponible para trabajo planificado.
/ 4. Sin ritmo de comunicación con stakeholders
Los updates pasaban cuando alguien los pedía — lo que significaba que el equipo era interrumpido constantemente para producir reportes ad-hoc. No había cadencia regular, ni formato consistente, ni entendimiento compartido de qué significaba “on track”.
/ 5. Equipo agotado
Varios developers trabajaban semanas de 50-60 horas tratando de compensar el proceso roto. El resultado no era más output — era más bugs, más retrabajo y resentimiento creciendo. Dos ingenieros senior ya habían decidido irse.
Lo que hicimos
Semanas 1-2: Parar y reiniciar
Congelamos todos los compromisos nuevos por un sprint. El equipo usó este tiempo para terminar items en progreso, limpiar el backlog de trabajo bloqueado y respirar. Fue una venta dura internamente — “¿el producto está atrasado y queremos que el equipo pare?” — pero era esencial. No se puede arreglar un sistema mientras corre a toda velocidad.
Medimos la realidad. Sacamos data de su herramienta de gestión de proyectos y calculamos el throughput real: el equipo completaba un promedio de 8 items por sprint en los últimos 6 meses. Se habían estado comprometiendo a 20+. La brecha era enorme pero no sorprendente.
Sistema de tracking de bloqueos. Regla simple: si algo está bloqueado más de 24 horas, se pone rojo en el tablero y se discute en el daily. Sin juicio — solo visibilidad.
Semanas 3-4: Nuevo ritmo
Compromisos del tamaño correcto.Basados en la data de throughput, el equipo se comprometió a 9 items para el siguiente sprint — apenas por encima de su promedio. La reacción fue mixta. Algunos sentían que era “muy fácil”. Explicamos: la meta no es trabajar menos. Es entregar lo que prometes. La confianza viene de la consistencia, no de la ambición.
Sync diario de 10 minutos. No un meeting de status. Tres preguntas: ¿qué se entregó ayer? ¿qué se hace hoy? ¿hay algo bloqueado? Si aparecía un bloqueo, se volvía la prioridad #1 del equipo — no mañana, ahora.
Email semanal a stakeholders.Cada viernes salía un update de un párrafo a los stakeholders del producto: qué se completó, qué se planea para la próxima semana, qué riesgos hay. Esto reemplazó las interrupciones ad-hoc tipo “¿cómo vamos?” y le dio al negocio una forma predecible de mantenerse informado.
Budget para trabajo no planificado.Asignamos 30% de la capacidad del equipo para manejar bugs, escalamientos y pedidos urgentes. Esto significaba planificar sólo el 70% de la capacidad total para items del roadmap. Al inicio el equipo se resistió — “¡vamos a entregar aún menos!”. En la práctica entregaron más, porque el trabajo planificado realmente se terminaba en lugar de ser desplazado por interrupciones.
Semanas 5-8: Optimizar y acelerar
Atacamos el bloqueo principal. La data mostraba que el 60% de los items bloqueados esperaban code reviews. Las reviews tomaban en promedio 2.5 días. Introdujimos un SLA de 4 horas: cada pull request se revisa en máximo 4 horas en horario de oficina. El autor hace pair con el reviewer si es complejo. En 2 semanas, el tiempo promedio de review bajó a 3 horas.
Reducimos WIP. El equipo pasó de 15+ items en progreso simultáneos a un máximo de 2 por developer. Se sintió restrictivo al inicio, pero el efecto fue inmediato: los items empezaron a moverse más rápido por el pipeline porque los devs se enfocaban en terminar, no en empezar.
Retros cada 2 semanas. Cada retro producía un experimento. Semana 5: standups async por Slack en vez de video (ahorró 50 min/día). Semana 7: checklist pre-review para detectar issues comunes antes de la review formal (redujo rondas de review 40%).
Los resultados
Después de 8 semanas, la transformación era medible en cada dimensión.
Qué hizo que funcionara
Mirando hacia atrás, la transformación se redujo a 4 cosas.
Honestidad sobre optimismo
El equipo dejó de comprometerse a lo que deseaba poder hacer y empezó a comprometerse a lo que realmente podía hacer. Este cambio simple construyó confianza con stakeholders y seguridad dentro del equipo.
Visibilidad sobre control
En lugar de tratar de micromanagear al equipo hacia el rendimiento, hicimos los problemas visibles temprano para que el equipo los resolviera solo. El sync diario y el tracking de bloqueos eran herramientas para el equipo, no vigilancia para la gerencia.
Terminar sobre empezar
Los WIP limits y los SLAs de review cambiaron el foco del equipo de “¿cuánto podemos empezar?” a “¿cuánto podemos terminar?”. Este solo cambio tuvo el mayor impacto en throughput.
Cambios pequeños, aplicados consistentemente
Sin transformación de proceso big-bang. Un experimento por retro, validado con data, conservado o descartado por resultados. Después de 8 semanas de mejoras pequeñas, el efecto acumulado fue dramático.
El takeaway
VittaSami no tenía un problema de talento. Tenía un problema de sistema. Los mismos ingenieros que entregaban al 40% se convirtieron en un equipo de 92% — sin una sola contratación nueva, sin una sola herramienta nueva, sin una sola hora extra por semana.
La diferencia fue un sistema de delivery que hacía los problemas visibles, los compromisos realistas y la mejora continua. Lo aplicamos en nuestro producto. Hoy es el mismo sistema que llevamos a otros equipos.
“Hicimos esto en VittaSami, nuestro propio producto. Los mismos ingenieros que entregaban al 40% pasaron a entregar al 92% — sin contratar a nadie nuevo, sin herramientas nuevas, sin horas extra. Podemos hacerlo en tu equipo también.”
¿Tu equipo está en una situación parecida?
Gente talentosa, delivery roto. 30 minutos, sin compromiso.
Agendar diagnóstico · 30 min →