El Scrum Master que también es tech lead y evalúa a su equipo
Nexo Retail tiene tres equipos Scrum. En el equipo Atlas, el Scrum Master, Diego, es además tech lead y dedica cerca del 60% de su jornada a escribir código en el servicio de pagos. En las últimas seis Sprints, Atlas se comprometió con 42, 40, 45, 38, 44 y 41 puntos, y entregó 29, 31, 30, 27, 33 y 28. Nadie menciona los bloqueos en el Daily Scrum; cuando aparecen, Diego los resuelve él mismo el mismo día y no los registra en ningún sitio. Cada retrospectiva produce entre tres y cinco acciones, pero al inicio de la Sprint siguiente ninguna está hecha y nadie sabe quién debía hacerlas. Negocio presiona porque el lanzamiento está fijado para el 15 de noviembre y pide que Diego «asegure el compromiso» del equipo. En conversaciones privadas, dos desarrolladores dicen que no se atreven a decir que no llegan porque Diego es quien evalúa su desempeño técnico y firma sus objetivos anuales.
1. Identifica los conflictos estructurales del caso y explica cómo cada uno produce los síntomas observados: brecha entre compromiso y entrega, bloqueos invisibles y acciones de retrospectiva no ejecutadas.
Read the worked answer
Los síntomas no apuntan a falta de capacidad: la entrega es estable (27-33 puntos) mientras el compromiso sube (38-45). Un patrón repetido seis veces es sistémico, no individual.
Conflicto 1: un mismo rol operativo y evaluador. Diego resuelve los impedimentos él mismo, lo que produce tres efectos encadenados: el impedimento no se hace visible para la organización y su causa raíz nunca se corrige; el equipo aprende que plantear bloqueos no sirve de nada; y quien debería facilitar la auto-organización se convierte en cuello de botella. Al evaluar el desempeño de las mismas personas a las que debe proteger, destruye la seguridad psicológica: nadie dice «no llego» en el Daily Scrum porque tiene coste político.
Conflicto 2: compromiso fijado por presión, no por capacidad. La brecha sostenida del 25-30% indica que las previsiones se negocian fuera del equipo y se aceptan por jerarquía. El equipo no se compromete: se somete.
Conflicto 3: retrospectivas sin dueño ni seguimiento. Las acciones no tienen responsable, fecha ni revisión en la siguiente Sprint, y el Scrum Master está programando en lugar de proteger la mejora.
Conclusión: los tres conflictos se refuerzan. Tratar solo el síntoma visible, es decir, presionar para que se cumplan las fechas, aumentará la ocultación de problemas y hará que la brecha se vuelva aún más difícil de ver.
2. Propón un plan de acción para las dos semanas siguientes, con orden justificado, y redacta qué le dices al patrocinador que exige «asegurar el compromiso» para el 15 de noviembre.
Read the worked answer
Orden: primero transparencia y seguridad, después estructura.
- Días 1-2, conversación privada con Diego. Sin acusaciones: presentar los datos (seis Sprints, misma brecha), explicar el conflicto de rol y pedirle que elija. Sin su acuerdo, cualquier cambio será cosmético.
- Día 3, Daily Scrum sin Diego como resolvedor. Regla explícita: los impedimentos se anotan en un tablero visible, con dueño y fecha. Diego facilita, no arregla.
- Días 4-7, retrospectiva reenfocada. Máximo dos acciones por Sprint, cada una con responsable, fecha y un check de seguimiento de cinco minutos al inicio de la siguiente retrospectiva.
- Semana 2, conversación con el patrocinador. No prometer compromiso; prometer previsibilidad.
Guion para el patrocinador, en tres frases: «Con los datos de las seis últimas Sprints, la capacidad real de Atlas está entre 27 y 33 puntos por Sprint. Puedo comprometerme a darte una previsión honesta y a que los riesgos se vean con antelación, no a que el equipo acepte 42. Si el 15 de noviembre es inamovible, la conversación útil es qué alcance entra y qué queda fuera, y necesito esa decisión esta semana.»
Clave: convertir la presión sobre el compromiso en una decisión de alcance, que es donde negocio sí tiene autoridad.
3. Evalúa las opciones reales para resolver la doble asignación de Diego y recomienda una, considerando que el lanzamiento es el 15 de noviembre y que retirarlo del código introduce riesgo.
Read the worked answer
Opción A: mantener el doble rol hasta el lanzamiento, con salvaguardas. Se nombra un facilitador rotatorio interno que recoge impedimentos y conduce el Daily Scrum, y se acuerda por escrito que Diego no resuelve bloqueos ajenos ni participa en evaluaciones de desempeño durante ese periodo. Coste bajo, riesgo bajo, pero no resuelve el conflicto de fondo.
Opción B: transferir el código a un tech lead distinto y dejar a Diego como Scrum Master a tiempo completo. Es la solución estructural correcta. Riesgo real: pérdida temporal de conocimiento en el servicio de pagos. Se mitiga con un traspaso de dos Sprints, revisión de código en pareja y una lista de los módulos críticos.
Opción C: rotar el Scrum Master desde otro equipo. Rápida, pero introduce a alguien sin contexto justo antes de una fecha crítica.
Recomendación: B con transición tipo A durante cuatro semanas. Justificación: el lanzamiento no se rompe por perder velocidad de codificación de una persona, se rompe por decisiones tomadas sin información y por un equipo que oculta riesgos. La doble asignación ya está costando más que el 60% de una jornada: cuesta la visibilidad de todos los impedimentos del equipo.
Condiciones de éxito: (1) el traspaso se planifica como trabajo del equipo, no como esfuerzo heroico; (2) se comunica a negocio que durante dos Sprints la velocidad puede caer y que eso está presupuestado; (3) la separación entre rol de facilitación y evaluación de desempeño se formaliza, no se deja a la buena voluntad.