044. Retrospectiva en servicios: mejorar el sistema, no buscar culpables

044. Retrospectiva en servicios: mejorar el sistema, no buscar culpables

En muchas empresas de servicios, cuando algo sale mal, la primera reacción suele ser buscar quién falló. Pero una buena Retrospectiva no va de eso. No va de señalar personas, repartir culpas o convertir el final del Sprint en una bronca elegante. Va de entender qué está pasando en el sistema. En este episodio hablamos de la Retrospectiva aplicada a empresas de servicios, especialmente en entornos de IT, soporte, mantenimiento, impresión corporativa, operaciones, incidencias, escalados N1/N2 y trabajo no previsto. Veremos por qué muchos problemas que parecen individuales en realidad son problemas del flujo: procesos poco claros, exceso de trabajo en curso, dependencias, interrupciones constantes, herramientas incómodas, falta de información, cuellos de botella o prioridades que cambian cada dos por tres. También veremos cómo una Retrospectiva bien planteada puede ayudar al equipo a pasar de la queja a la mejora, de la culpa a la causa raíz y de la frustración a una acción concreta para el siguiente Sprint. Conectaremos este Evento con la Teoría de las Restricciones, porque cuando el mismo bloqueo aparece una y otra vez, ya no estamos ante una anécdota: estamos ante una señal clara del sistema. Este episodio forma parte de la serie basada en el libro “Cómo transformar empresas de servicios con Agile, Scrum y TOC”, de José Manuel Hernández Agudo, donde llevamos Scrum, Agile y TOC al terreno real de las empresas de servicios. Una idea clave del episodio: La culpa cierra conversaciones. La causa raíz las abre. La Retrospectiva no debería responder solo a la pregunta: “¿qué ha ido mal?” Debería ayudarnos a responder otra mucho más útil: ¿Qué vamos a cambiar para que el sistema funcione mejor? Cada audio es independiente y forma parte de un plan de formación sobre Agile, Scrum y TOC aplicados a empresas de servicios.

043. Sprint Review en servicios: enseñar valor real, no solo tareas terminadas

En muchas empresas, la Sprint Review se entiende como una demo, una presentación de tareas acabadas o una reunión para enseñar que el equipo ha estado ocupado. Pero una Sprint Review bien hecha va mucho más allá. No se trata solo de responder a la pregunta: “¿Qué hemos hecho?” La pregunta importante es otra: ¿Qué ha mejorado gracias a lo que hemos hecho? En este episodio hablamos de la Sprint Review aplicada a empresas de servicios, donde el valor no siempre se ve en una pantalla nueva o en una funcionalidad terminada. A veces el valor está en reducir incidencias repetitivas, mejorar tiempos de respuesta, eliminar esperas, reducir escalados innecesarios, aclarar un procedimiento, mejorar la trazabilidad o hacer que el servicio funcione con menos fricción. Veremos por qué cerrar tareas no siempre significa entregar valor, cómo convertir la Review en una conversación útil con clientes, usuarios y responsables del servicio, y por qué el feedback es clave para adaptar el Product Backlog y decidir mejor los siguientes pasos. También conectaremos la Sprint Review con la Teoría de las Restricciones, porque no todas las mejoras mejoran realmente el sistema. Una mejora local puede parecer positiva, pero si no ayuda al flujo ni al cuello de botella, quizá solo hemos estado muy ocupados. Este episodio forma parte de la serie basada en el libro “Cómo transformar empresas de servicios con Agile, Scrum y TOC”, de José Manuel Hernández Agudo, donde aplicamos Scrum, Agile y TOC a servicios reales, no solo a desarrollo de software. Una idea clave del episodio: Una tarea cerrada no siempre es valor entregado. La Sprint Review no debería ser una reunión de escaparate. Debería ser una conversación honesta sobre valor, aprendizaje, feedback y mejora del servicio. Cada audio es independiente y forma parte de un plan de formación sobre Agile, Scrum y TOC aplicados a empresas de servicios.

042. Sprint Planning en servicios: planificar sin olvidarse de la operación diaria

Planificar un Sprint en una empresa de servicios no es tan sencillo como llenar una lista de tareas y esperar que todo salga perfecto. Porque en servicios siempre aparece la realidad. Incidencias urgentes, llamadas de cliente, escalados de N1 a N2, mantenimientos, averías, problemas de stock, visitas técnicas, cambios de prioridad y trabajo no previsto. Por eso, una Sprint Planning bien hecha no consiste en meter más trabajo en el Sprint, sino en construir un plan realista, compartido y sostenible. En este episodio hablamos de cómo aplicar la Sprint Planning en empresas de servicios, especialmente en entornos de IT, soporte, mantenimiento, impresión corporativa y operaciones recurrentes. Veremos por qué muchas planificaciones nacen rotas desde el principio: se planifica como si no existieran las incidencias, como si toda la capacidad del equipo estuviera disponible y como si el cuello de botella pudiera absorberlo todo. También veremos el papel del Sprint Goal, la importancia de reservar capacidad para la operación diaria, cómo distinguir entre trabajo planificado y trabajo no previsto, y por qué el equipo debe participar activamente en la construcción del plan. Además, conectaremos la Sprint Planning con la Teoría de las Restricciones, porque planificar sin mirar dónde está el cuello de botella puede acabar generando más atasco, más presión y menos flujo. Una idea clave del episodio: Una Sprint Planning que ignora la operación diaria nace rota. Planificar bien no es imaginar una semana perfecta. Planificar bien es mirar la realidad de frente, elegir bien, proteger el foco y construir un compromiso que el equipo pueda sostener. Cada audio es independiente y forma parte de un plan de formación sobre Agile, Scrum y TOC aplicados a empresas de servicios.

041. La Daily Scrum en empresas de servicios: coordinar sin convertirla en una reunión de seguimiento

La Daily Scrum es uno de los Eventos más conocidos de Scrum… y también uno de los peor entendidos. En muchas empresas de servicios acaba convertida en una reunión diaria de seguimiento, donde cada persona informa de lo que hizo, se justifican retrasos, se revisan tickets uno a uno y alguien termina dirigiendo la conversación como si fuera un parte operativo. Pero la Daily Scrum no va de controlar al equipo. Va de coordinarse. Va de mirar si el Sprint avanza, detectar bloqueos, ajustar el plan del día y proteger el flujo de trabajo. En este episodio hablamos de cómo aplicar la Daily Scrum en empresas de servicios, especialmente en entornos de soporte, mantenimiento, operaciones IT, impresión corporativa, incidencias, escalados N1/N2 y trabajo no previsto. Veremos por qué una mala Daily puede generar más presión, más justificación y menos autonomía; y cómo una buena Daily puede ayudar al equipo a recuperar control, visualizar bloqueos y tomar mejores decisiones cada día. También conectaremos la Daily con la Teoría de las Restricciones, porque cuando un mismo bloqueo aparece una y otra vez, quizá no estamos ante una simple incidencia, sino ante una señal clara del sistema. Una idea clave del episodio: La Daily Scrum no pertenece al jefe. Pertenece al equipo. Y cuando se usa bien, deja de ser “otra reunión más” para convertirse en una herramienta diaria de coordinación, aprendizaje y mejora del servicio. Cada audio es independiente y forma parte de un plan de formación sobre Agile, Scrum y TOC aplicados a empresas de servicios.

040. Cuando Scrum en servicios se convierte en teatro: roles, eventos y tableros sin cambio real

En este episodio cerramos la serie dedicada a los roles y figuras de Scrum en empresas de servicios con una reflexión incómoda, pero muy necesaria. A veces una empresa dice que trabaja con Scrum porque tiene Scrum Master, Product Owner, Equipo Scrum, Daily, Sprint, backlog, tablero y retrospectivas. Pero, en el fondo, todo sigue funcionando igual que antes. La dirección sigue cambiando prioridades cada pocos días. El jefe sigue repartiendo tareas. La Daily se convierte en un parte de situación. El backlog se llena sin criterio. La retrospectiva no cambia nada. Y el equipo sigue sin autonomía real. Eso es lo que podríamos llamar Scrum de teatro: cuando se adoptan los nombres, los Eventos y las herramientas, pero no cambia la forma de decidir, priorizar, colaborar y aprender. En una empresa de servicios, este riesgo es especialmente alto, porque el día a día viene cargado de incidencias, urgencias, SLA, clientes exigentes, interrupciones y presión operativa. En este episodio veremos cómo detectar cuándo Scrum se ha convertido en una simple apariencia y qué podemos hacer para recuperar su verdadero sentido: crear transparencia, mejorar el flujo, reducir bloqueos y ayudar al equipo a trabajar mejor. Porque Scrum no consiste en cambiar el decorado. Consiste en cambiar la forma de trabajar. Cada audio es independiente y forma parte de un plan de formación sobre Agile, Scrum y TOC aplicado a empresas de servicios.