Llega un líder nuevo al área de Producto. Mira el caos. Carryover del 30% sprint a sprint, gente apagando incendios, releases que se postergan sin explicación clara. Y dice lo que todo el mundo dice cuando aterriza en una situación así: "tenemos que implementar Scrum bien".
Se contrata un coach ágil. Hay tres semanas de capacitación. Se arman ceremonias prolijas. Daily, planning, review, retro. A los tres meses está todo igual.
Si te pasó dos o tres veces, ya sabés que el problema está en otro lado. Y sin embargo es lo primero que la mayoría de los equipos vuelve a intentar.
Por qué Scrum (o Kanban, o Shape Up) no arregla lo que está roto
Los frameworks de gestión asumen cosas que en muchos equipos de Producto no se cumplen. Asumen que hay roles definidos. Que las personas que entran al sprint saben qué tienen que entregar y por qué. Que hay alguien definiendo qué entra al backlog con algún tipo de prioridad sostenible. Que el equipo tiene capacidad de estimar.
Cuando esas cosas no están, Scrum no las construye. Las hace visibles, eso sí. Pero la visibilidad sola no resuelve.
Lo que termina pasando es que el equipo aprende a hacer ceremonias. Llega puntual a la daily, mueve cards en Jira, hace una retro que dura una hora y produce dos action items que nadie sigue. La forma se respeta. El fondo sigue igual.
Lo que está roto cuando el framework no toma
En los equipos de Producto que llevan tres intentos fallidos de metodología, hay tres cosas que suelen estar pasando al mismo tiempo.
Una persona carga demasiado. Generalmente el Head, a veces un PM senior, a veces el fundador. Esa persona es la única que conoce el contexto completo. El equipo no puede tomar decisiones sin ella, así que todo el trabajo pasa por su escritorio. Cualquier framework que dependa de autonomía distribuida se rompe contra ese cuello de botella.
Los roles están escritos pero no operan. En el papel hay un PM, un Tech Lead, un Designer. En la práctica las responsabilidades se mezclan, las decisiones se duplican, hay tareas que caen entre dos personas y tareas que las hacen tres. Ningún sprint ordena eso. Lo que ordena eso es una conversación dura sobre quién decide qué.
No hay trazabilidad de impacto. El equipo entrega features, pero no sabe si esos features mueven algo. Sin métricas que cierren el loop, cada release se siente igual que la anterior. La motivación cae. La discusión sobre qué hacer la próxima semana se vuelve política en lugar de basada en lo que aprendimos.
Si vas a invertir tiempo y plata en mejorar cómo trabaja tu equipo, esos tres frentes te van a dar más retorno que cualquier framework nuevo.
Por dónde se empieza
El orden que funciona es feo porque va al revés de lo que la mayoría intenta.
Primero hay que mapear quién decide qué. No lo que dice el organigrama, lo que pasa en la práctica. Se hace con una conversación honesta con cada persona del equipo, preguntando por casos concretos. "Cuando aparece un pedido de Ventas, ¿quién lo evalúa? ¿Quién lo prioriza? ¿Quién lo comunica al equipo?". Las respuestas inconsistentes te marcan dónde está el problema.
Segundo, hay que descargar a la persona que está sobrecargada. Eso no se hace pidiéndole que delegue. Se hace eligiendo dos o tres tipos de decisiones que hoy pasan por ella y armando, para cada una, qué información necesita el equipo para decidir solo. Esto requiere construcción de marco, no solo voluntad.
Tercero, hay que poner una métrica que importe. Una. No un dashboard. Una métrica que el equipo entero revise cada semana y que lo obligue a discutir qué aprendieron, no qué entregaron.
Recién después de eso, si todavía hace falta, conviene hablar de framework. La mayoría de las veces el "problema con Scrum" se evapora cuando los tres puntos anteriores empiezan a funcionar.
El punto
Si tu equipo intentó implementar metodología ágil más de una vez y la sensación es que volvió a quedar igual, no estás solo. Es un patrón. Lo que pasa es que el ruido del framework tapa el problema de fondo, que tiene que ver con roles, con autonomía y con cómo el equipo se relaciona con el impacto de lo que hace.
Ese tipo de trabajo difícilmente lo cubra un coach ágil. Lo cubre alguien que entienda Producto como disciplina, no solo como proceso.
Si querés revisar qué está rompiendo a tu equipo y armar un plan para resolverlo, ProductPrepa for Business es un programa de hasta tres sesiones con un temario armado a partir de los desafíos puntuales de tu equipo. Antes de arrancar hay una conversación de alineación para definir el contenido. Podés escribirme a nicoproducto@hey.com con el asunto "ProductPrepa for Business" para arrancar.
Abrazo de Producto, NicoProducto