Los dos capítulos anteriores te dieron el ideal: el marco de Scrum y la herramienta donde vive. Sobre el papel, todo encaja —roles claros, tablero ordenado, ceremonias en su sitio—. Ahora toca la otra cara, la que nadie te cuenta en la primera semana: lo que de verdad acaba pasando cuando ese proceso tan pulcro se encuentra con una empresa real, con sus prisas, sus jefes y sus prioridades que cambian.
Esto no es para volverte cínico ni para que pienses que Scrum es un timo. Es para que reconozcas los patrones cuando los veas —y los vas a ver— y sepas navegarlos. La distancia entre la teoría y la práctica no es un fracaso de tu equipo: es lo normal. Quien la entiende juega con ventaja; quien la ignora se frustra pensando que lo hace todo mal.
Por qué se tuerce#
Scrum funciona si se dan sus supuestos: un equipo dedicado, un Product Owner presente y accesible, pocas interrupciones de fuera y unas prioridades razonablemente estables. La realidad de muchas empresas es otra: las personas están repartidas entre dos o tres proyectos, el PO aparece a ratos y responde tarde, entran urgencias a mitad de sprint y lo que era prioridad el lunes deja de serlo el jueves.
Cuando le quitas a Scrum esas condiciones, el marco cruje. Y aparece el híbrido más común de la industria, el water-scrum-fall: el equipo hace dailies, sprints y retros por dentro, pero está rodeado de waterfall —la dirección fijó el alcance y la fecha completos al principio, y no se tocan—. El resultado es lo peor de los dos mundos: la ceremonia ágil sin su beneficio (no puedes responder al cambio, porque el plan está cerrado) y la rigidez de waterfall sin su planificación cuidada.
El test del “¿y qué?”: el proceso no falla por el proceso, falla porque le retiran lo que necesitaba. Saber esto cambia dónde pones la energía. No en seguir el ritual a rajatabla, sino en pelear por las condiciones —un PO accesible, un sprint protegido— que lo hacen funcionar.
El daily que es un parte de estado#
El ideal: una reunión corta donde el equipo se coordina y saca bloqueos. Lo que pasa: el manager entra “para enterarse de cómo va cada uno”, y la daily se convierte en un parte de estado hacia arriba. La gente deja de hablarle al equipo y le habla al jefe.
¿Por qué ocurre? Porque a quien gestiona le da seguridad ver el avance, y la daily parece el sitio. ¿Y qué se rompe? En cuanto la reunión se dirige al jefe, cada uno informa de que “todo va bien” para no parecer el que va lento, y los bloqueos —lo único que la daily debía destapar— se esconden hasta que explotan. La reunión sigue ocurriendo cada mañana, pero ya no sirve para lo que la justificaba.
Qué hacer: no se trata de echar al manager del mundo, sino de darle el estado que necesita por otra vía (el tablero ya lo muestra, o un resumen escrito) y reconducir la daily a su propósito. Un buen Scrum Master hace justo esto. Y por tu parte, usa la daily para lo que es: di tu bloqueo real, aunque quede feo. Es lo más útil que puedes aportar ahí.
La estimación que se vuelve deadline#
El ideal: estimas en story points para planificar, sabiendo que son esfuerzo relativo, no tiempo. Lo que pasa: alguien sin ese contexto oye “5 puntos”, lo traduce a “el jueves” y lo promete a un cliente. Tu estimación, pensada para ordenar el trabajo, se ha convertido en un compromiso de fecha que tú no hiciste.
¿Y qué? Esa fecha inventada vuelve como deadline. Para cumplirla, el equipo recorta calidad (sin tests, sin revisar) o echa horas. Y, como nadie quiere que le pase, la siguiente vez todos inflan las estimaciones “por si acaso”, con lo que los puntos dejan de medir nada.
Qué hacer: cortar la traducción a tiempo antes de que cuaje. Si te piden una fecha, no des un número pelado: da un rango con sus supuestos. “Cinco puntos es un esfuerzo medio; con lo que ya hay en el sprint, una previsión realista es la semana que viene, salvo que aparezca un bloqueo.” Una fecha con su incertidumbre comunica honestidad; un punto disfrazado de promesa es una trampa que se cierra sobre ti.
La retro sin consecuencias#
El ideal: el equipo mira cómo trabajó y sale con mejoras. Lo que pasa: retro tras retro se repiten las mismas quejas —“las historias llegan poco claras”, “nos interrumpen mucho”— y nada cambia.
¿Por qué? Porque la retro se queda en identificar el problema y no llega a la acción. ¿Y qué se rompe? El equipo aprende que la retro no sirve para nada (impotencia aprendida): deja de proponer, la reunión se vuelve un desahogo y acaba siendo la primera que todos quieren saltarse.
Qué hacer: salir con una o dos acciones concretas, con dueño, y revisarlas al principio de la siguiente retro. “A partir de ahora los criterios de aceptación se escriben en el refinement” es una acción; “deberíamos comunicarnos mejor” no lo es. Mejor una mejora pequeña que de verdad ocurre que diez intenciones que se evaporan.
El scope creep y la “cosita rápida”#
El ideal: el sprint backlog se acuerda en el planning y se respeta. Lo que pasa: a mitad de sprint llega un “ya que estás con el roster, métele también esto, es rápido”. Lo aceptas porque parece pequeño y porque decir que no incomoda. Eso es scope creep: el alcance creciendo a base de añadidos no planificados.
¿Y qué? Cada extra parece inofensivo, pero el sprint estaba comprometido: lo que entra obliga a que algo salga, aunque nadie lo diga. Si los aceptas todos, el objetivo del sprint se diluye y al final no entregas ni lo planificado ni los extras —solo un montón de cosas a medias—.
Qué hacer: no ser inflexible, pero hacer visible el intercambio. “Puedo meterlo, pero entonces el filtro se va al próximo sprint; ¿lo ve bien el PO?” Así el coste deja de ser invisible y la decisión la toma quien debe tomarla, con la información delante. El Scrum Master, otra vez, está para protegerte de esto.
La deuda técnica contra la presión de entregar#
La deuda técnica es lo que cuesta de más en el futuro por una solución rápida o poco cuidada de hoy: copiar y pegar en vez de extraer, saltarte los tests, dejar un “TODO: arreglar esto”. Y aquí toca ser honesto, porque es tentador soltar “nunca tomes deuda técnica” y quedarse tan ancho.
La verdad es más matizada: a veces tomarla es la decisión correcta. Hay una fecha real e inamovible, o estás validando un prototipo que quizá se tire a la basura; en esos casos, correr y ya pulir después es sensato. La deuda técnica es como una deuda financiera: pedirla puede ser buena jugada si te da algo a cambio.
El problema son los intereses. Cada cambio sobre código apresurado cuesta un poco más, y si nunca devuelves la deuda, esos intereses se acumulan. ¿Y qué pasa al final? La velocidad del equipo se desploma, lo que antes era un día se vuelve tres, y llega el temido “eso no se puede tocar sin romper algo”. Lo que mata no es contraerla, es no pagarla nunca bajo la presión constante de la siguiente entrega.
Qué hacer: tomarla con los ojos abiertos y hacerla visible. Un atajo consciente se anota como un ticket de deuda, no se esconde. Y se negocia con el PO reservar algo de capacidad de cada sprint para devolverla, en vez de esperar al “sprint de limpieza” mítico que nunca llega.
Las reuniones que podrían ser un mensaje#
Lo que pasa: el calendario se llena de reuniones —de sincronización, de seguimiento, de alineación— hasta que no queda hueco para programar. Y siempre hay alguien proponiendo una reunión más “para estar más alineados”.
¿Y qué? Más reuniones no es más alineación. Cada una parte el día y cuesta el doble por el cambio de contexto al volver al código. Un equipo reunido a todas horas acaba sin tiempo para hacer el trabajo del que tanto habla.
Qué hacer: async por defecto. Mucho de lo que se trata en reunión es en realidad información que cada uno podría leer cuando pueda: un mensaje, un documento, un comentario en el ticket. Eso libera las reuniones para lo que de verdad las necesita —una decisión difícil, un conflicto, una sesión de diseño—. Ante una reunión sin agenda clara, está bien preguntar “¿esto podría ser un mensaje?”.
Navegar, no despreciar#
Visto todo esto, es fácil caer en uno de dos extremos. El cínico concluye que Scrum es un fraude y rechaza cualquier proceso; acaba en el caos, porque sin un mínimo de estructura un equipo no se coordina. El fanático sigue el manual al pie de la letra pase lo que pase; choca una y otra vez contra la realidad y quema al equipo defendiendo el ritual.
El profesional hace otra cosa: lee la situación. El marco es una herramienta. Cuando te sirve, lo usas; cuando no, lo adaptas —que es, literalmente, lo que pedía el manifiesto ágil con eso de “responder al cambio por encima de seguir un plan”—. No idealizas el proceso ni lo desprecias: lo pones a trabajar para el equipo, no al revés.
Comprueba lo que sabes#
Pregunta 1 de 11