scrum master roles

El Rol del Scrum Master


“Sí sí pero… ¿qué hace exactamente un Scrum Master?”

Pregunta que me han hecho en repetidas veces, realmente es difícil de contestar, puesto que depende de muchas cosas. En este artículo trataré de explicar los roles que normalmente desempeña un Scrum Master. También qué responsabilidades tiene y en qué actividades o tareas concretas suelen transformarse.

Lo primero es definir qué es un Scrum Master. Dentro del equipo Scrum existen 3 roles con responsabilidades muy marcadas:

  • Product Owner: Como su propio nombre indica, es la persona encargada del producto: Marca la visión del producto, lo define, toma las decisiones sobre lo que se debe construir y cuándo construirlo, valida y decide cuándo una funcionalidad sale al mercado. En resumen, es responsable del “QUÉ”.
  • Dev Team: Son las personas necesarias para construir el producto. Idealmente el equipo es multidisciplinar y debe ser capaz de llevar una funcionalidad explicada por el product owner a producción. Por tanto en el Dev Team hay analistas, testers, devops, base de datos, frontend, backend, etc. En resumen, es responsable del “CÓMO” a nivel técnico.
  • Scrum Master: Es la persona encargada de que respeten los principios y dinámicas Scrum, de crear un entorno en equilibrio en el que fluya la comunicación y se consigan resultados. En resumen, es responsable de la dinámica de todo el equipo Scrum.

scrum master daily

Para conseguir este fin tan etéreo y nebuloso el Scrum Master adoptará uno o varios roles según el contexto. Los principales son los siguientes:

  • Facilitador, es el rol que mejor define a un Scrum Master. En líneas generales, se trata de focalizar al grupo en que éste consiga unos objetivos concretos, sin llegar a contribuir directamente. Típicamente el Scrum Master hace de facilitador en todas las reuniones de Scrum. Especialmente difíciles son las reuniones diarias y las retrospectivas.
  • Dueño del proceso, a todos los niveles. Más allá de facilitar las ceremonias Scrum deberá asegurar que hay un equilibrio entre Dev Team y Product Owner, que las reuniones son efectivas, que el backlog está bien ordenado y refinado, que se cumplen los compromisos adquiridos en los acuerdos de trabajo, etc. En caso de que esto no suceda nuevamente deberá ejercer el liderazgo para conseguirlo. Por ejemplo si ve que no hay suficientes historias preparadas para el siguiente refinement, el Scrum Master podría ofrecer su ayuda al Product Owner priorizar y dividir algunas épicas.
  • Líder servil, en el que el Scrum Master fomenta la autoorganización del equipo, potenciando las cualidades de los individuos, desde la humildad y la confianza. Este liderazgo no pretende marcar una visión y llevar al equipo hacia ella, sino hacer que el equipo encuentre su propio camino y eliminar los posibles obstáculos. Cuando el Scrum Master elimina impedimentos (por ejemplo reservando una sala para una reunión adhoc) o resuelve un conflicto (habla con el Product Owner para que no interrumpa tanto en los dailies) está ejerciendo un liderazgo servil.
  • Coach, tanto personal como del equipo al completo. Como coach el Scrum Master hace reflexionar a base de preguntas para que la otra persona o equipo encuentre sus propias respuestas. Es la aproximación favorita del Scrum Master, ya que es mucho más fácil comprometerse con algo si ese algo lo has ideado tú. Un ejemplo de coaching puede ser hacer preguntas a un miembro del equipo para que encuentre cómo quiere proseguir en su carrera profesional, en una sesión one-on-one. Ejemplos de coaching de equipos los tendremos a patadas en las retrospectivas. En lugar de proponer al equipo que haga pair programming, es preferible preguntar al equipo: ¿cómo mejorarías la calidad del código? ¿la comunicación? ¿las revisiones de código? ¿la transferencia de conocimiento? El equipo llegará solo a la solución y será más fácil que la adopten.
  • Agente de cambio, muchas veces más allá del equipo Scrum. Mantiene la visión de hacia dónde debe dirigirse la compañía y lidera las iniciativas de cambio para cumplir esa visión. Este papel frecuentemente va más allá del equipo Scrum, es decir, es muy posible que para lograr conseguir mejoras deba provocar cambios fuera del ámbito del equipo. Un ejemplo típico de Scrum Master provocando cambio es hacer conscientes a stakeholders y managers de una deuda técnica desproporcionada, de un backlog insuficiente o excesivo, de la necesidad de invertir en formación, de dejar espacio para la mejora continua, de que stakeholders asistan y participen en la reviews, etc.
  • Motivador, en los casos en los que se necesite una dosis extra de motivación. El ser humano tiende a enfocarse en lo negativo (sesgo de negatividad), por lo que es fácil caer en el desánimo y la desmotivación si algo no sale como se esperaba. Es frecuente desempeñar este papel en las retrospectivas. Cuando haces memoria de un periodo de tiempo es fácil acordarse solo de lo que no ha ido bien. El Scrum Master apunta a lo conseguido en anteriores sprints, comportamientos positivos, hábitos adquiridos, etc. Se trata de poner equilibrio, no de distorsionar la realidad.
  • Mentor, ya que generalmente el Scrum Master tiene más experiencia que los miembros del equipo, es común que se establezca una relación de mentor y aprendiz. La relación puede ser más o menos formal, y puede ser sobre varias temáticas dependiendo de la experiencia e intereses de ambos. Ejemplos concretos son un [[onboarding]] del Scrum Master a alguien que acaba de entrar al equipo, o hacer pair programming para enseñar cómo hacer TDD.
  • Profesor, nuevamente aprovechando sus conocimientos y experiencias, suele ser frecuente que un Scrum Master proponga sesiones sobre Agile, TDD, Clean Code, patrones de diseño, GTD y otros temas relacionados. No es necesario que sean sesiones multitudinarias, preparadas y planificadas, pueden ser charlas esporádicas improvisadas o conversaciones de café.
  • Gestor, en las ocasiones en que el equipo necesite ayuda o le suponga una distracción. Por ejemplo a la hora de dar acceso al equipo a una impresora o de tramitar una licencia de software. Es un papel muy secundario y no debe ser el foco del Scrum Master, y éste debe encontrar que el equipo sea lo más autoorganizado posible. Por ejemplo el caso típico de las vacaciones. Es mucho mejor si el Scrum Master transmite los criterios y restricciones existentes y es el equipo el que se organiza y decide sus propias vacaciones.

scrum master coach

En esencia lo que hace un Scrum Master continuamente es pensar. Analizar el contexto del equipo y luego buscar la manera de ayudarlo a mejorar y a conseguir resultados. Para ello el Scrum Master deberá actuar dentro del área de influencia del equipo pero muchas veces también fuera de él.

Espero haber conseguido transmitirte cual es el papel del Scrum Master. Si no lo he conseguido, por favor, no dudes en preguntar en los comentarios cualquier duda que tengas. Estaré encantado de responder.

También te puede interesar...

Crea ya tu lista de impedimentos en Scrum El rol del Scrum Master incluye eliminar impedimentos, pero ¿qué son los impedimentos en Scrum concretamente?¿Qué debe hacer el Scrum Master?¿cuáles d...
Resumen Scrum by Jeff Sutherland Tenía muchas ganas de leer este libro. Ya no solo porque era leer sobre el framework Scrum que utilizo a diario en mi trabajo, sino porque me lo había...
Resumen User Stories Applied de Mike Cohn ¿Qué es una historia de usuario?¿qué elementos debe cumplir?¿cómo se crean? El libro User Stories Applied de Mike Cohn nos da respuesta a éstas y c...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

4 ideas sobre “El Rol del Scrum Master

  • David Sorsa

    Gracias Samuel por el post..llevaba tiempo buscando uno en el que resumiera (bien) el trabajo de un SM y qué se le debe decir a la gente sobre el trabajo del día a día del rol..

    En otros sitios había oido lo mismo de siempre…que si facilitar, que si ayudar a infundir la autogestión del equipo, que si proteger dicho equipo, etc…

    Pero joder…no había visto la clave…PENSAR….un SM, piensa, coño…tan dificil es de entender y que se te pague por ello?

    Tienes que, además, programar, o gestionar proyectos, o hacer microinformatica?….que no…PENSAR, ese es nuestro trabajo…

    Si lo envidiais, o no lo comprendéis…vosotros mismos, haceros SM e interiorizar el rol y veréis que es así…

    Un saludo desde Valencia …te sigo…
    David Sorsa

    • samuelcasanova Autor

      Hola David.
      Parece una perogruyada pero sí, un SM debe pensar y aplicar el sentido común en su trabajo. Y no solo eso, el SM debe provocar también que el resto de personas reflexione y aplique sentido común de forma sistemática. Si no no está haciendo bien su trabajo de lograr cambio.
      Un placer tenerte por el blog, David.
      Nos leemos.

  • Miguel

    Buenas

    Muy buen articulo.

    Al final he llegado a la conclusión después de leer y escuchar a muchos coach y otros SMs que la verdadera fuente de verdad de Scrum es la “Guía de Scrum”. En la guía se explica lo que es un SM en un folio por una cara (lo que no este aquí no es Scrum). Hay dos punto que me gustan mucho (lo pongo tal cual):

    – Ayudar al DevTeam a crear productos de alto valor
    – Motivar cambios que incrementen la productividad del DevTeam.

    Creo que son dos puntos fáciles de entender y muy potentes.

    Un saludo

    • samuelcasanova Autor

      Hola Miguel.
      La guía Scrum es sin duda una referencia indispensable para cualquiera que esté en este mundillo.
      Para los que no están en él, sin embargo, la guía no es suficiente para hacerse una idea de en qué actividades concretas se traducen esas metas del SM. Pienso que no es el objetivo de la guía, ya que Scrum es un marco de trabajo abierto y debe adaptarse siempre a las circunstancias.
      En el artículo mi intención era ilustrar las que han sido en mi experiencia esas actividades. Así si alguien no lo ve claro al menos se pueda hacer una idea, pero que quede claro que son mis experiencias y que en otras circunstancias seguro habría que adaptarlas.
      Gracias por comentar, Miguel.