Preguntas de entrevista para Scrum Master

Respuesta modelo

Respondo de la efectividad del equipo y de que el marco de trabajo se entienda y se use para algo, no para cumplir un rito. En concreto: facilito los eventos para que produzcan decisiones, hago visible el flujo de trabajo, elimino o escalo los impedimentos, acompaño al equipo y a la Propiedad de Producto, y trabajo con la organización para que deje de generar bloqueos. Lo que no es mío: decidir qué se construye y en qué orden, que es de Producto; y comprometer alcance, presupuesto o fechas contractuales, que corresponde a quien dirige el proyecto o el área. Sí aporto información para esas decisiones —por ejemplo, un pronóstico basado en el rendimiento histórico del equipo con su nivel de confianza—, pero la decisión y el compromiso no son míos. En mi último equipo esa frontera fue explícita: cuando dirección quería una fecha, yo entregaba el rango probabilístico y era la Product Owner quien decidía qué recortar del alcance para encajarlo.

Respuesta modelo

El aprovisionamiento de entornos de prueba en la plataforma de pagos. Cada entorno se pedía por formulario a Infraestructura y tardaba entre 12 y 18 días, así que cada sprint terminaba con trabajo a medio hacer esperando entorno. Lo primero fue dejar de quejarme y medirlo: durante seis sprints registré días de espera por elemento y el porcentaje de trabajo bloqueado por esa causa, que era el 34 %. Con ese dato pedí quince minutos en el comité técnico, presenté el coste en días de espera de los dos equipos y propuse dos opciones concretas en lugar de un problema abierto: una plantilla automatizada en Terraform que el equipo pudiera lanzar por sí mismo, o una capacidad reservada de Infraestructura. Acordamos las dos: plantilla para los casos estándar y cuatro horas semanales reservadas para lo excepcional. El tiempo por entorno bajó de dos semanas a menos de dos días y recuperamos unos 31 días de espera por trimestre. Me llevó cuatro meses y dos negativas iniciales.

Respuesta modelo

Miro tres planos y ninguno por separado. El flujo: tiempo de ciclo por percentil 85 en lugar de la media, rendimiento por sprint, edad del trabajo en curso y cantidad de trabajo simultáneo. La calidad: defectos escapados a producción, tiempo medio de recuperación y retrabajo. Y la salud del equipo: participación real en las retrospectivas, acciones cerradas, rotación voluntaria y una encuesta breve repetida siempre con la misma pregunta y la misma escala. En mi último equipo pasamos de 18 a 6 días de tiempo de ciclo del percentil 85, de 12 a 3 defectos escapados por trimestre y de 6,1 a 8,2 en la encuesta de salud, todo en cuatro trimestres. Deliberadamente no uso la velocidad como indicador de rendimiento ni comparo equipos entre sí: la velocidad es una unidad de calibración interna, y en cuanto se convierte en objetivo el equipo infla estimaciones y el dato deja de servir para planificar.

Respuesta modelo

Primero acepto que es responsabilidad mía, porque normalmente ocurre porque yo estoy en el centro de la sala y hago las preguntas. Cambio dos cosas. La primera, mi posición física y verbal: dejo de preguntar y me sitúo fuera del círculo; si hace falta, me ausento de dos o tres Dailies para romper el hábito. La segunda, el objeto de la conversación: paso de la ronda de personas a la lectura del tablero de derecha a izquierda, empezando por lo más cercano a terminado, lo más antiguo y lo bloqueado. La pregunta deja de ser qué hiciste ayer y pasa a ser qué necesitamos para cumplir el objetivo del sprint y qué está atascado. En mi equipo eso redujo el Daily de 26 a 11 minutos y, lo más importante, los bloqueos empezaron a salir el mismo día en lugar de aparecer en el Sprint Review. Después lo llevé a la retrospectiva para que el cambio lo acordara el equipo y no lo impusiera yo.

Respuesta modelo

Mi trabajo es que sus decisiones sean más fáciles de tomar y de ejecutar, no tomarlas. En la práctica hago tres cosas. Le doy datos que no tiene: coste real de las dependencias, tiempo de ciclo por tipo de trabajo, pronóstico probabilístico para que pueda decidir alcance con un nivel de confianza en lugar de con una promesa. La acompaño en la formulación del objetivo de sprint orientado a resultado y en criterios de aceptación verificables; con Example Mapping y QA presente desde el principio bajamos el refinamiento de 3 horas a 75 minutos y las historias devueltas por indefinición de 7 a 1. Y protejo la conversación: si a mitad de sprint entra trabajo nuevo, no digo que no —no es mi decisión—, sino que hago explícito qué sale a cambio y qué pasa con el objetivo del sprint. La frontera para mí es clara: yo no priorizo el backlog ni decido el roadmap; si alguna vez lo hice fue porque la organización tenía un hueco, y eso es un impedimento que hay que resolver, no un mérito.

Respuesta modelo

No lo introduzco: lo propongo como experimento acotado y dejo que el equipo decida. Empiezo por hacer visible el problema con un dato que les duela a ellos, no a mí; por ejemplo, enseñar que el 40 % del trabajo terminado se quedaba esperando revisión más de cuatro días. Luego propongo una prueba con límite temporal, normalmente dos sprints, con un criterio de éxito acordado de antemano y el compromiso explícito de volver atrás si no funciona. Ese compromiso es la clave: la resistencia casi nunca es al cambio, es al cambio irreversible impuesto desde fuera. Y elijo una sola cosa cada vez. Con el equipo de pagos empezamos únicamente por limitar el trabajo en curso a dos elementos por persona durante dos sprints; funcionó, el tiempo de ciclo bajó y a partir de ahí el equipo propuso el resto de cambios por su cuenta. Cuando un experimento fracasa, lo digo en la retrospectiva y lo retiramos: eso compra más credibilidad que tres aciertos seguidos.

Respuesta modelo

Doy información, no compromisos, porque el compromiso no es mío. Concretamente entrego un pronóstico basado en el rendimiento histórico del equipo: con los datos de los últimos veinte sprints, una simulación de Monte Carlo dice que ese alcance se termina antes del 15 de octubre con un 85 % de confianza y antes del 30 de septiembre con un 50 %. A partir de ahí la conversación cambia de naturaleza: dejamos de discutir si el equipo se esfuerza y pasamos a decidir alcance y riesgo, que es una decisión de Producto y de dirección. Además pongo sobre la mesa lo que sí depende de nosotros: las dependencias abiertas y el trabajo en curso simultáneo, que suelen ser la causa real de que las fechas se muevan. Lo que no hago es prometer una fecha por evitar la incomodidad de la reunión: eso funciona una vez y destruye la confianza durante un año.

Respuesta modelo

Después de un incidente grave en producción convoqué una retrospectiva especial y cometí dos errores. El primero, invitar a la responsable del área sin avisar al equipo: nadie habló de lo que había pasado de verdad y la sesión se quedó en generalidades. El segundo, entrar directamente a buscar la causa técnica sin dedicar tiempo a bajar la tensión, con dos personas que se sentían señaladas. Salimos con tres acciones vacías. Lo reconocí al día siguiente ante el equipo, pedí disculpas por la invitación no acordada y repetimos la sesión solo con el equipo, empezando por una línea temporal de hechos sin nombres propios y con la regla explícita de que buscábamos condiciones del sistema, no personas. De ahí salieron dos acciones reales: alertas sobre el flujo crítico de pagos y una lista de comprobación previa al despliegue de los viernes. Desde entonces acuerdo siempre la asistencia con el equipo antes de invitar a nadie de fuera.

El lead time lo mide el cliente: desde que se pide algo hasta que está disponible. El tiempo de ciclo lo mide el equipo: desde que empieza a trabajarlo hasta que lo termina según la Definition of Done. La diferencia entre ambos es la espera antes de empezar, y en la mayoría de las organizaciones españolas con las que he trabajado esa espera es mayor que el trabajo en sí; por eso el lead time suele ser la conversación más incómoda y más útil. Uso percentiles y no medias porque la distribución de estos tiempos no es simétrica: tiene una cola larga de elementos que se atascan, y la media la esconde. Decir que el 85 % de los elementos se termina en seis días o menos es una promesa que se puede usar para acordar un nivel de servicio; decir que la media son cuatro días no sirve para nada, porque nadie recuerda las historias medias, todo el mundo recuerda la que tardó cinco semanas.

Con el histórico de rendimiento y una simulación de Monte Carlo. Tomo cuántos elementos terminó el equipo por semana o por sprint durante los últimos tres o seis meses, sorteo miles de combinaciones de esas semanas históricas y obtengo una distribución de fechas de finalización para un número dado de elementos. El resultado se expresa siempre con nivel de confianza: 85 % de probabilidad antes del 15 de octubre, 50 % antes del 30 de septiembre. Requiere dos condiciones: que los elementos estén troceados con un tamaño más o menos homogéneo —yo divido todo lo que supere cinco días— y que las fechas de inicio y fin estén bien registradas en la herramienta. La ventaja frente a los puntos es doble: se elimina el gasto de tiempo de la estimación colectiva y desaparece la discusión sobre si el equipo cumple o no cumple, porque hablamos de probabilidad y no de promesa.

Es un acuerdo explícito sobre cuántos elementos pueden estar en marcha a la vez, en el equipo o en una columna concreta. Funciona por la ley de Little: con un rendimiento estable, cuanto más trabajo simultáneo haya, mayor es el tiempo de ciclo. El número no se calcula en un despacho, se descubre. Yo empiezo midiendo el trabajo en curso actual sin cambiar nada durante dos o tres sprints, y normalmente aparece un número escandaloso: en mi último equipo, catorce elementos abiertos con ocho personas. A partir de ahí propongo un límite ligeramente por debajo del promedio observado —dos por persona en aquel caso— y lo revisamos cada dos sprints mirando el tiempo de ciclo y la edad del trabajo en curso. Lo importante es lo que ocurre cuando se alcanza el límite: la regla debe ser que nadie empieza algo nuevo, sino que se ayuda a terminar lo que está más avanzado. Ahí es donde el equipo aprende de verdad a acabar en lugar de a empezar.

Tres cosas, por este orden. El ensanchamiento de las bandas: si una banda intermedia crece de forma sostenida, ahí hay un cuello de botella y trabajo acumulándose sin salir; el caso más típico es la banda de revisión o de validación con Producto. La pendiente de la línea de terminado: si se aplana, el equipo ha dejado de entregar aunque siga ocupado, lo que casi siempre significa demasiado trabajo abierto a la vez. Y las escaleras: si la línea de entrada sube a saltos grandes, es que el trabajo entra en lotes, normalmente porque alguien vuelca todo el sprint el primer día. Con esas tres lecturas suelo tener la conversación de la retrospectiva ya preparada. Y siempre lo comparo con la edad del trabajo en curso, porque el diagrama muestra el sistema pero no dice qué elemento concreto lleva veintitrés días abierto, que es lo que hay que resolver hoy.

Son cuatro indicadores de capacidad de entrega: frecuencia de despliegue, tiempo de entrega del cambio, porcentaje de despliegues fallidos y tiempo medio de recuperación. No son mías —dependen de decisiones de ingeniería—, pero sí son la conversación que más impacto tiene en el flujo del equipo, así que mi trabajo es hacerlas visibles y ayudar a que se prioricen las mejoras técnicas que las mueven. En la práctica eso significó defender ante Producto un porcentaje fijo de capacidad para automatización de pruebas y despliegue, y traducir a lenguaje de negocio por qué desplegar dos veces por semana en lugar de una vez al mes reduce el riesgo en lugar de aumentarlo. En dos trimestres pasamos de un despliegue mensual a dos semanales y el tiempo medio de recuperación bajó de 5,5 a 1,8 horas. Conviene añadir un matiz: en entidades financieras españolas hay que encajar esto con el comité de cambios y con los requisitos de trazabilidad, y esa negociación es también parte del trabajo.

Recomiendo Kanban cuando el trabajo llega de forma imprevisible y no se puede comprometer un objetivo de sprint con sentido: soporte, mantenimiento, plataformas internas con peticiones de otros equipos. Ahí un sprint se rompe cada semana y el ritual acaba desmoralizando. Con un equipo de mantenimiento pasamos a clases de servicio —urgente, estándar y fecha fija—, límites de WIP por columna y un acuerdo de servicio de cinco días para la clase estándar, que cumplimos en el 91 % de los casos frente al 58 % anterior. Scrum lo prefiero cuando hay un producto con objetivos que se pueden formular por sprint y un espacio real para inspeccionar y adaptar. De la revisión de 2020 destaco tres cambios: desaparece el concepto de rol y se habla de responsabilidades, con el equipo Scrum como una sola unidad sin subequipos; se introduce el Compromiso del Producto y se añade el objetivo de producto junto al objetivo de sprint y a la Definition of Done; y se elimina la referencia a las tres preguntas del Daily, que era justo lo que convertía ese evento en un informe de estado.

No lo trato en la retrospectiva, porque un conflicto personal expuesto en grupo casi siempre empeora y además rompe la seguridad del resto. Hablo primero por separado con cada una, escuchando sin buscar quién tiene razón e intentando entender qué necesita cada cual: en el caso que viví, una quería revisiones de código más rigurosas y la otra sentía que se le bloqueaba el trabajo por detalles de estilo. Después les propuse una conversación conjunta, facilitada por mí, con una regla clara: hablar de hechos y de necesidades, no de intenciones. De ahí salió un acuerdo concreto, que es lo que hace que el conflicto no vuelva: una guía de estilo automatizada con el analizador estático para que la máquina discutiera el formato, y un límite de veinticuatro horas para revisar. La tensión bajó en dos semanas. Si no hubiera funcionado o hubiera habido faltas de respeto, habría escalado a la responsable de las personas: hay conflictos que exceden mi papel y pretender resolverlos yo sería un error.

Primero mido, porque sin dato la conversación es una queja. Durante tres sprints registré cuántos elementos entraban después del inicio, de dónde venían y qué se quedaba sin terminar por ello: eran cuatro o cinco por sprint y arrastrábamos entre el 30 % y el 40 % del trabajo. Con eso hablé a solas con la Product Owner, no en público, y descubrí lo que suele haber detrás: no era capricho, era presión de Dirección Comercial y falta de un canal para lo urgente. Acordamos dos mecanismos. Uno, una capacidad reservada del 20 % del sprint para lo imprevisto, de modo que lo urgente tuviera sitio sin romper el objetivo. Dos, una regla explícita: si entra algo por encima de esa reserva, ella misma dice qué sale y lo comunica al equipo. Las interrupciones bajaron a una por sprint y el cumplimiento del objetivo subió del 45 % al 86 %. Lo importante es que la decisión siguió siendo suya: mi trabajo fue hacer visible el coste y ofrecer un mecanismo, no impedirle priorizar.

Lo paro, pero con argumento y con alternativa, no con una lección de ortodoxia. Explico que la velocidad es una unidad de calibración interna: cada equipo estima con su propia escala, así que comparar equipos es como comparar temperaturas en escalas distintas. Y añado la consecuencia práctica, que es la que convence: en cuanto la velocidad se premia, las estimaciones se inflan y perdemos la única herramienta que teníamos para planificar; el número sube y la entrega real no se mueve. Luego ofrezco lo que sí es comparable entre equipos porque se mide en unidades objetivas: tiempo de ciclo, rendimiento, defectos escapados a producción, tiempo medio de recuperación y frecuencia de despliegue. En el banco donde me pasó, propuse un panel con esas cinco métricas y con una regla escrita de que se usarían para detectar impedimentos del sistema y nunca para evaluar personas. Se aceptó y, además, ese panel acabó sirviendo para justificar la inversión en automatización de despliegues.

Doy por hecho que tiene parte de razón y empiezo por ahí. Le pedí un café y le pregunté qué evento concreto le parecía inútil y por qué; su respuesta fue precisa: el refinamiento duraba tres horas, se hablaba de historias que no se harían en meses y él salía sin haber aportado nada. Era cierto. En lugar de defender el marco, convertí su crítica en el tema de la siguiente retrospectiva y el equipo acordó refinar solo lo que entraría en los dos sprints siguientes, con una hora de límite y con QA presente; bajamos a 75 minutos. A partir de ahí dejó de saltarse el evento, no porque yo se lo pidiera, sino porque empezó a servirle. Con quien se resiste por principio y no por experiencia, mi enfoque es distinto: acuerdo con esa persona un mínimo irrenunciable —normalmente el objetivo de sprint y la Definition of Done— y dejo de pelear por la forma. Y si el comportamiento afecta al resto del equipo, lo llevo al acuerdo de equipo para que sea el grupo quien lo trate, no yo en solitario.

No haría la retrospectiva de siempre, porque el formato habitual con el ánimo bajo produce una lista de quejas y ninguna acción. Prepararía una sesión con datos y sin personas: una línea temporal de los tres sprints con los hechos —qué entró, qué se bloqueó, cuándo, cuánto tiempo estuvo parado cada elemento— construida a partir del tablero y no de la memoria. Empezaría por bajar la tensión reconociendo en voz alta que los tres sprints han ido mal y que el objetivo de la sesión no es repartir culpas sino entender el sistema. Luego usaría los cinco porqués sobre los dos bloqueos más caros y no sobre los diez que hubo, porque con el ánimo bajo hay que salir con una victoria pequeña y clara, no con un plan de doce puntos. Terminaría con una única acción, con responsable y fecha, y con el compromiso de revisarla al inicio del siguiente sprint. Si el patrón viene de fuera del equipo —dependencias, entornos, interrupciones—, la acción sería mía y organizativa, y así se lo diría al equipo: es importante que vean que la carga no es solo suya.

Lo primero es decirlo con claridad y por escrito: con tres equipos no puedo dar el mismo acompañamiento y prefiero acordar qué se va a atender peor que fingir que llego a todo. Después priorizo por necesidad real, no por reparto igualitario: normalmente hay un equipo con un problema agudo que necesita presencia diaria, y otros dos más maduros que funcionan con un contacto semanal y las retrospectivas facilitadas por ellos mismos por rotación. Con esos dos me centro en dejar mecanismos que no dependan de mí: acuerdos de equipo escritos, Definition of Done clara, tablero que se lea solo y un canal para que los impedimentos me lleguen sin esperar a la reunión. Y me reservo un bloque fijo, en mi caso una jornada semanal, para los impedimentos organizativos, porque son los que afectan a los tres a la vez y los que nadie más va a mover. Por último, presento cada trimestre a mi responsable el coste de la situación con datos —qué equipo se ha quedado sin acompañamiento y qué se ha degradado—, porque el reparto excesivo es un impedimento organizativo como cualquier otro y hay que hacerlo visible.