Lo que debes saber de los primeros 90 días como scrum master
Descubre qué ocurre en los primeros 90 días como scrum master, los errores más comunes, consejos prácticos y el rol en la era de la IA.
Entre el momento en que estudias para ser scrum master y el primer sprint en un equipo real hay una distancia que no se mide en puntos de historia.
Saber lo que te espera no elimina esa distancia, pero puede evitar que te pille por sorpresa.
Lo que esperas como scrum master y lo que encuentras
Cuando estudias para ser scrum master construyes un modelo mental bastante preciso de cómo funciona el rol: los eventos, los artefactos, las responsabilidades, la dinámica del equipo. Tienes claro qué hace un buen SM y cómo se ve un equipo que funciona bien.
El problema es que el primer equipo real no siempre se parece a él.
No porque el modelo esté mal, sino porque una cosa es entender cómo debería funcionar scrum y otra es encontrarte con una organización concreta, con su historia, su cultura y sus inercias: un equipo que lleva años trabajando de una manera determinada, un product owner con doce reuniones al día, una dirección que aprobó "hacer scrum" sin terminar de entender lo que eso implica en el día a día, etc.
Esa distancia entre las expectativas y la realidad es universal. No depende de cómo hayas aprendido, es que un equipo real no siempre es un caso de libro. Reconocerlo es el primer paso para no frustrarte cuando el territorio no coincide con el mapa.
Los errores más comunes
Conocerlos no garantiza evitarlos, sin embargo, ayuda a detectarlos antes de que se conviertan en un problema mayor.
1. Implementar antes de observar
Es el error más frecuente. Tienes claro qué hay que hacer, y quieres hacerlo bien. El resultado es que celebras todos los eventos, respetas los timeboxes, explicas los roles con paciencia... y te frustras cuando el equipo no responde como esperabas.
Es probable que todavía no hayas aprendido a leer el contexto en el que operas. Scrum es un marco intencionalmente incompleto: lo que funciona en un equipo maduro con autonomía real, puede no funcionar igual en un equipo que lleva años bajo una gestión muy directiva o que acaba de empezar con scrum. Tu primera tarea no es implementar. Es observar y entender.
2. Confundir facilitar con resolver
Cuando el equipo tiene un problema, el impulso natural es solucionarlo. No obstante, hay una diferencia importante entre eliminar un impedimento real que el equipo no puede resolver por sí solo, y resolver cualquier fricción antes de que el equipo tenga la oportunidad de gestionarla.
Un scrum master que resuelve todo priva al equipo de la oportunidad de desarrollar su propia capacidad de autogestión. Y un equipo que no se autogestiona depende del SM para funcionar, que es exactamente lo contrario de lo que buscas.
3. Subestimar la política organizacional
El scrum master no opera en el vacío. Opera en una organización con intereses, jerarquías y dinámicas de poder que no desaparecen porque el equipo adopte un framework ágil. Ignorar esa realidad es una de las razones más comunes por las que las implantaciones de scrum generan menos impacto del esperado: no por falta de conocimiento técnico, sino por falta de comprensión del contexto organizativo en el que se aplica.
Entender quién toma las decisiones reales, qué miedos hay detrás de la resistencia al cambio y cómo navegar esas conversaciones es tan importante como saber cuánto dura un sprint planning.
4. Hablar más de lo que escuchas
Un scrum master principiante tiende a explicar, a justificar, a enseñar. Es lógico: tienes conocimiento fresco y quieres aportarlo. Pero en los primeros meses, la escucha vale más que cualquier explicación.
Las conversaciones, las tensiones que no llegan a la retrospectiva, los silencios en la daily... ahí está la información que más necesitas para entender qué está pasando realmente en el equipo. Y esa información solo aparece si creas el espacio para que emerja.
Consejos prácticos para los primeros 90 días como scrum master
Observa antes de intervenir
Los primeros 30 días son de observación. Asiste a los eventos, toma notas, haz preguntas. Resiste el impulso de cambiar cosas antes de entender por qué están como están. Muchas dinámicas que desde fuera parecen disfuncionales tienen una historia detrás que conviene conocer antes de actuar. No asumas nada. Recopila información, datos y pruebas.
Invierte en la relación con el product owner
La relación entre el scrum master y el product owner es una de las más determinantes para el funcionamiento del equipo. Si esa relación no funciona, el equipo lo nota. Dedica tiempo a entender sus prioridades, sus presiones y su visión del producto. No para estar de acuerdo en todo, sino para poder colaborar desde el entendimiento. De nuevo, recopila información antes de crearte ideas o asumir nada.
Haz de la retrospectiva tu herramienta principal
La retrospectiva es el evento donde más puedes influir en los primeros meses. No como protagonista, sino como facilitador de conversaciones que el equipo necesita tener. Una buena retrospectiva es la que consigue que el equipo hable con honestidad sobre lo que está pasando.
La investigadora Amy Edmondson lleva décadas estudiando la dinámica de los equipos de alto rendimiento. Su trabajo sobre seguridad psicológica muestra que los equipos no mejoran cuando se les dice cómo hacerlo, sino cuando sienten que es seguro experimentar, cometer errores y hablar de ellos abiertamente. Tu trabajo en la retrospectiva (y en general) es crear ese espacio y mantenerlo.
Aprende a influir sin autoridad formal
El scrum master no tiene autoridad formal sobre nadie. No asigna tareas, no evalúa, no decide. Su influencia es lateral, basada en la confianza y la credibilidad que construye con el tiempo. Puede generar inseguridad al principio: ¿cómo influyo sin poder?
La respuesta práctica: haciendo preguntas, haciendo visible lo que el equipo no ve, y creando las condiciones para que las conversaciones importantes ocurran. Es un tipo de liderazgo que se aprende con la práctica. Y los primeros 90 días son el mejor momento para empezar.
Busca referentes y comunidad
Lee, habla con otros que están viviendo los mismos retos. Busca comunidades de práctica, foros, grupos donde los profesionales del rol compartan experiencias reales y teoría. El contraste con otras realidades te ayudará a calibrar la tuya.
El scrum master en la era de la IA
La inteligencia artificial ya está cambiando cómo trabajan los equipos de desarrollo: puede generar código, sugerir técnicas de facilitación, analizar métricas de flujo, tomar notas en retrospectivas y proponer mejoras de proceso. Eso es una realidad.
Sin embargo, hay una distinción fundamental: la IA es tecnología, no equipo. No desarrolla relaciones de confianza, no gestiona las dificultades de dinámica de grupo que emergen en un equipo, no lee el silencio en una retrospectiva tensa ni construye la confianza que hace posible la autogestión.
Y esas son exactamente las competencias que definen el valor de un scrum master que evoluciona con el rol. Un análisis de Xebia Academy sobre el futuro de los equipos ágiles sitúa al SM de 2030 como un líder centrado en estrategia de transformación, coaching organizacional y gobernanza de sistemas de trabajo híbridos humano-IA. Alejado de la operativa diaria, más cerca del liderazgo de cambio.
El riesgo real no es que la IA sustituya al scrum master. El riesgo es que un scrum master cuyo valor se define únicamente como facilitador de eventos quede expuesto. Porque eso puede asistirlo la IA. Lo que no puede replicar es la inteligencia emocional, el pensamiento sistémico y la capacidad de guiar a un equipo a través de la incertidumbre.
Hay otro elemento que añade urgencia al rol: con la IA los equipos pueden construir funcionalidades mucho más rápido de lo que las organizaciones pueden validar. McKinsey identificó en su State of AI 2025 que la adopción de IA es amplia pero el impacto en resultados de negocio sigue siendo escaso en la mayoría de organizaciones. El factor diferencial no es la herramienta adoptada, sino haber rediseñado los flujos de trabajo en profundidad. Alguien tiene que facilitar esa conversación. Alguien tiene que ayudar al equipo a preguntarse no solo si puede construirlo, sino si debería. Ese alguien es el scrum master.
Paradójicamente, la IA hace que los primeros 90 días sean más importantes que nunca. Porque es ahí donde decides qué tipo de scrum master vas a ser: el que sólo aplica la teoría, o el que aprende a leer el contexto, facilitar la complejidad y generar valor donde ninguna herramienta puede hacerlo por ti.
Para seguir aprendiendo
Si estás en tus primeros meses como scrum master, o si te estás preparando para serlo, en nuestra web encontrarás materiales y recursos de referencia (plantillas, herramientas interactivas, apuntes, etc.). También puedes acceder de forma gratuita a nuestra wiki y a la comunidad de Open Knowledge.
Hazte miembro del Club Agile (gratis el primer año si te certificas con algún centro oficial de Scrum Manager) para acceder a recursos exclusivos, mantenimiento de tus PDAs y para practicar tus habilidades en distintos ámbitos de la agilidad en Skill Arena: desde IA aplicada a la agilidad hasta historias de usuario y OKR.
Bibliografía
Edmondson, A. (1999). "Psychological Safety and Learning Behavior in Work Teams". Administrative Science Quarterly, 44 (2), 350–383.
McKinsey & Company (2025). The State of AI: How Organizations Are Rewiring to Capture Value. McKinsey QuantumBlack.
Schwaber, K. & Sutherland, J. (2020). The Scrum Guide.
Scrum Manager (2026). Guía Scrum Master. Scrummanager.com.
Xebia Academy (2025). Scrum Teams In 2030: The Future Of Agile With AI. Academy.xebia.com.
Comentarios (8)
Jorge Sánchez López ★★★
25/03/2026 14:22Hay una imagen idílica que todos compramos cuando estudiamos para ser Scrum Master: un equipo autogestionado, pizarras llenas de notas adhesivas de colores y un flujo de trabajo perfecto.
Luego llega el primer lunes. Te encuentras con una organización que tiene prisa, un Product Owner desbordado y un equipo que te mira como si fueras un antropólogo examinando una tribu extraña.
En mis años como formador y mentor organizacional, he visto a muchos profesionales brillantes fallar no por falta de conocimiento, sino por exceso de teoría. Si quieres que tus primeros tres meses cuenten, deja de lado el manual un momento y hablemos de la realidad.
Se nos dice que los primeros 30 días son para observar. Es un consejo con trampa. Si te limitas a mirar, la organización concluirá que eres un gasto innecesario.
Tu observación debe ser estratégica y activa. No esperes un mes para aportar valor. Busca una victoria temprana o logro rápido: arregla ese acceso que el equipo lleva pidiendo semanas, elimina esa reunión que todos odian o clarifica una prioridad confusa. La autoridad no te la da tu certificado; te la da tu capacidad para despejar el camino.
Existe la creencia de que el SM nunca debe dar soluciones para no romper la autogestión del equipo. Esto es un error de bulto en entornos de crisis.
Si el equipo tiene un bloqueo externo y tú te limitas a hacer "preguntas reflexivas", estás siendo un obstáculo, no un líder. Tu trabajo es ser un rompe-muros. Elimina las piedras del camino hoy para que el equipo pueda aprender a caminar solo mañana. La fluidez del trabajo está por encima del purismo metodológico.
Muchos SM novatos se centran en los eventos y las métricas, ignorando que las decisiones reales se toman en pasillos o en reuniones de dirección a las que no están invitados.
No trabajas en un laboratorio, trabajas en una organización con jerarquías, miedos y juegos de poder(Te recomiendo el arte de la guerra, El principe...). Entender quién tiene el veto real y quién se siente amenazado por la agilidad es tan importante como saber gestionar el Backlog. Sin inteligencia política, tus propuestas de cambio morirán en un cajón.
A estas alturas, sabemos que la Inteligencia Artificial analiza las métricas de flujo y detecta cuellos de botella mejor que cualquier humano. Pero la IA no sabe leer la tensión en un silencio durante una Retrospectiva ni sabe cómo motivar a un desarrollador quemado. (Afortunadamente para tí, tienes un poder que no eres consciente, a continuación te lo explico)
No compitas con los datos; úsalos. Deja que la tecnología haga el análisis frío y dedica tu energía a lo que ninguna máquina puede replicar: la estrategia de cambio y la resolución de conflictos humanos. Ese es el terreno donde un SM de alto nivel se vuelve indispensable.
Olvida el "agilismo de salón". Los primeros 90 días son una prueba de resistencia y pragmatismo. No busques que el equipo sea perfecto; busca que sea mejor que ayer.
Duro con los problemas. Cercano con las personas. Y con la claridad suficiente para saber cuándo aplicar la teoría, cuándo adaptarla y cuándo tener el criterio de apartarla.
Porque al final, la agilidad no va de seguir un método. Va de entregar valor en organizaciones reales, con personas reales y con toda la complejidad que eso conlleva. Y eso, por mucho que lo intente, ningún examen de certificación lo va a enseñar. O puede que necesites un mentor, un estudiante de medicina hace el MIR antes de ejercer como profesional, lo has pensado.
Gracias Scrum Manager por poner estos debates sobre la mesa.
Canal Scrum ★
25/03/2026 16:02Buena síntesis de tensiones reales que cualquier SM reconocerá: la observación activa, la inteligencia política, saber cuándo apartar el manual.
Todo eso está en el día a día del rol.
En cuanto a lo de las certificaciones, ¿crees que el marco conceptual y la práctica se excluyen? Más bien se necesitan. El MIR que mencionas lo ilustra bien: la residencia existe porque antes hay carrera.
Gracias por participar y, sobre todo, por aportar tu experiencia.
Jorge Sánchez López ★★★
26/03/2026 00:11Gracias por la respuesta, y precisamente porque el debate merece más que un cierre amable, voy a matizar.
Nadie ha dicho que el marco y la práctica se excluyan. Lo que he dicho es algo diferente: que el peso que ponemos en la certificación como señal de competencia profesional es desproporcionado respecto a lo que esa certificación realmente acredita. Y eso tiene consecuencias en cómo llegan al rol los profesionales que formamos.
La analogía del MIR es buena, pero me sirve para lo contrario de lo que propones. El sistema MIR funciona precisamente porque nadie confunde el título de medicina con la capacidad de operar. La residencia existe, dura años y ocurre bajo supervisión real porque hay un consenso explícito de que la teoría sola no es suficiente. En nuestra profesión ese consenso no existe, o existe en el discurso pero no en la práctica de contratación ni en los itinerarios de desarrollo profesional.
La pregunta que lanzo no es si necesitamos el marco. Es si estamos siendo honestos sobre lo que la certificación garantiza y lo que no. Y si esa honestidad, o la falta de ella, está produciendo profesionales bien examinados pero mal equipados para el conflicto real.
Esa tensión no se resuelve diciendo que ambas cosas se complementan. Se resuelve diseñando mejor el puente entre las dos.
Canal Scrum ★
26/03/2026 11:26Estamos de acuerdo en buena parte de lo que dices. La agilidad va de entregar valor en contextos reales, con personas reales, y eso no se aprende solo con un examen. Hasta ahí, totalmente contigo.
Ahora bien, conviene no confundir la parte con el todo. Una certificación académica no pretende enseñarte a lidiar con la complejidad de una organización real; lo que hace es asegurarse de que conoces las bases. Y sin las bases, es muy difícil aprender de la experiencia. Volviendo al ejemplo del MIR: nadie espera que un médico sepa operar solo por haber estudiado anatomía, pero tampoco querríamos que alguien entre en un quirófano sin haberla estudiado.
La formación académica te da el conocimiento sobre el que construir. La práctica te da el criterio. Y si lo que quieres es acreditar que además de saber la teoría estás ejerciendo con un nivel profesional contrastado y te mantienes al día, para eso existen otros mecanismos: las certificaciones profesionales, que se renuevan anualmente con valoraciones reales de clientes y compañeros, o los diplomas de evaluación de Skill Arena, que validan competencias prácticas en áreas concretas.
El puente entre las dos es complementar las dos. El conocimiento sin práctica se queda corto, pero la práctica sin conocimiento suele llevar a repetir errores que otros ya resolvieron.
Jorge Sánchez López ★★★
26/03/2026 11:31Se llama SHU HA RI.
Recomiendo ver KARATE KID😊👌
Canal Scrum ★
26/03/2026 11:38O leer este artículo 😁: https://scrummanager.com/community/entre-la-adaptacin-y-la-degeneracin-la-lnea-invisible-que-decide-si-scrum-sigue-siendo-scrum
Jorge Sánchez López ★★★
26/03/2026 11:41SHU ¿Sería FORMACIÓN y CERTIFICACIÓN?
Canal Scrum ★
26/03/2026 11:44¿Así quedaría?
Shu → Formación y certificación
Ha → Práctica y mentoría (espacios como el Club Agile, Skill Arena o la mentoría que tú ofreces)
Ri → Criterio propio