Preguntas de entrevista Scrum Master

La resistencia a Scrum generalmente proviene de una de tres fuentes: malas experiencias pasadas con un marco mal implementado, miedo a que la transparencia exponga el rendimiento individual, o un desajuste genuino entre Scrum y el tipo de trabajo real del equipo. Mi primer paso es escuchar en lugar de defender el marco. Mantengo reuniones individuales para entender las objeciones específicas y buscar patrones. Si la resistencia tiene que ver con malas prácticas pasadas, lo reconozco y distingo qué haremos de forma diferente. Si tiene que ver con la transparencia, ayudo al equipo a entender que las ceremonias Scrum les protegen del trabajo no planificado y las expectativas poco realistas. Si el trabajo genuinamente no encaja con Scrum, exploro Kanban o un enfoque híbrido en lugar de imponer un marco a un equipo para quien no funcionará. Mi trabajo es servir al equipo, no imponer una metodología.

Una retrospectiva que parece un ejercicio de casilla que marcar generalmente significa que el equipo no cree que su feedback lleve a cambios. Mi primer movimiento es abrir la sesión revisando los puntos de acción de la retrospectiva anterior y siendo honesto sobre qué pasó con cada uno. Si la mitad no se siguieron, lo nombro. Luego cambio el formato: en lugar de la misma estructura "fue bien / podría mejorar", pruebo una técnica diferente, como un ejercicio de línea de tiempo, un radar de felicidad o una retrospectiva "barco de vela". Estas iniciativas cambian la energía y provocan conversaciones diferentes. También reduzco el número de puntos de acción a uno o dos, con un propietario específico y una definición de hecho. Los equipos se desconectan de las retrospectivas cuando producen largas listas que nadie lleva a cabo.

La diferencia central está en la autoridad y la responsabilidad. Un gestor de proyectos normalmente posee la entrega: mantiene el calendario, el presupuesto y la responsabilidad de cumplir los hitos. Un Scrum Master posee el proceso: facilita, orienta y elimina impedimentos, pero no posee lo que se construye ni cuándo se entrega. Un gestor de proyectos gestiona personas hacia un plan. Un Scrum Master permite que un equipo se gestione a sí mismo. En la práctica, muchas organizaciones contratan Scrum Masters pero los tratan como gestores de proyectos, lo que es una de las causas más frecuentes de disfunción ágil. Mi rol es orientar al equipo hacia la auto-organización, mantener las ceremonias y proteger al equipo de las interferencias externas.

El equipo con el que trabajaba perdía dos o tres horas por sprint en un proceso manual de promoción de entornos gestionado por un equipo de infraestructura separado. Cada despliegue requería un ticket, un período de espera y pasos manuales que solo dos personas en la organización sabían realizar. Primero calculé el impacto completo en varios equipos y lo cuantifiqué: aproximadamente 25 horas-persona por sprint en tres equipos Scrum. Luego presenté esos datos al director de ingeniería y propuse un spike de 30 días para automatizar el proceso. Facilité la colaboración entre el equipo de desarrollo y el equipo de infraestructura y mantuve a ambas partes informadas. La automatización tardó cuatro semanas en implementarse y redujo el tiempo de promoción de entornos de 90 minutos a menos de cinco.

Dos desarrolladores senior del equipo tenían una tensión continua sobre los estándares de revisión de código. Uno abogaba por revisiones exhaustivas con comentarios detallados; el otro encontraba el proceso lento y desmoralizante. El conflicto se manifestaba en los stand-ups como desacuerdo pasivo y ralentizaba el flujo de pull requests. Realicé un breve ejercicio estructurado durante una retrospectiva: ambos desarrolladores escribieron de forma independiente su definición de una buena revisión de código, luego las comparamos. Sus valores fundamentales estaban en realidad alineados, pero discrepaban en la inversión de tiempo y el estilo de los comentarios. Acordamos un convenio de trabajo: las revisiones se completarían en 24 horas y los comentarios distinguirían entre problemas bloqueantes y sugerencias. En dos sprints, el tiempo de ciclo de los PR bajó un 30% y la tensión interpersonal se había resuelto en gran medida.

El Product Owner con el que trabajaba tenía un backlog de más de 200 elementos, muchos de ellos vagos y sin estimar. Las sesiones de planificación del sprint regularmente se pasaban del tiempo y terminaban con el equipo sin claridad sobre a qué se había comprometido. Mantuve una reunión individual con el PO y reencuadré el backlog como una herramienta de comunicación, no un sistema de archivado. Acordamos una regla simple: los 20 primeros elementos deben estar listos para el sprint, definido por una Definición de Preparado ligera. Facilité una sesión de cirugía del backlog de dos horas donde cerramos 60 elementos que no se habían tocado en seis meses. Las sesiones de planificación del sprint se redujeron de 3 horas a 90 minutos en un mes.

Uso una combinación de señales cuantitativas y cualitativas. En el lado cuantitativo sigo la tendencia de la velocidad (no el número absoluto, sino si es estable o volátil), la tasa de logro del objetivo del sprint y la proporción entre trabajo planificado y no planificado en cada sprint. Un equipo con mucho trabajo no planificado generalmente tiene un problema de protección, no de capacidad. En el lado cualitativo realizo una revisión trimestral de salud del equipo usando un radar ligero: nos evaluamos en colaboración, claridad de objetivos, seguridad psicológica y confianza en el proceso. Las puntuaciones importan menos que la conversación que provocan. También observo las sprint reviews: si las partes interesadas se sorprenden constantemente con lo que el equipo construyó, algo se ha roto en el bucle de comunicación.

Lo primero que hago es diagnosticar la causa en lugar de asumir que el equipo tiene bajo rendimiento. Las razones más frecuentes son: las stories son demasiado grandes y no se han descompuesto correctamente, la velocidad está sobreestimada por un optimismo en la planificación, hay demasiado trabajo no planificado que entra a mitad de sprint, o la Definición de Hecho se aplica de forma inconsistente. Analizo los últimos tres a cinco sprints y categorizo las stories incompletas por causa raíz. Si las stories son demasiado grandes, realizo un taller de división. Si el equipo se sobre-compromete, introduzco una zona de amortiguación en la planificación. Si las interrupciones a mitad de sprint son el problema, trabajo con las partes interesadas para crear un canal formal para solicitudes urgentes que no eluda el proceso Scrum.

La resistencia al cambio en los equipos casi siempre tiene que ver con la incertidumbre y la pérdida de competencia. Las personas expertas en la forma actual de trabajar se convierten de repente en principiantes, lo que resulta incómodo. Mi enfoque es hacer la transición gradual y distinguir entre tiempo de aprendizaje y tiempo de entrega, para que no se espere que el equipo entregue a plena velocidad mientras también aprende una nueva tecnología o proceso. Organizo sesiones de trabajo en parejas entre quienes están más cómodos con el cambio y quienes lo están menos. Ajusto los compromisos del sprint a la baja durante el período de transición y comunico ese ajuste a las partes interesadas de forma proactiva. También realizo una retrospectiva estructurada en el punto medio de la transición para comprobar si el enfoque está funcionando.