Apenas unos días antes de que se decretase el estado de alarma, me habían pedido, en una reunión de mi departamento, que me preparase una sesión para contar qué (o quién) es un Scrum Master…en 30 minutos.

Cuando empecé a prepararme esta charla pensé: Yo esto lo puedo contar o en dos segundos o en cuarenta horas, pero en 30 minutos… ¿Qué tipo de información puedo (debo) dar en 30 minutos y que clarifique exactamente el papel que juega este rol en Scrum?

Así que, como casi cada vez que me toca contar algo, mi forma de enfocarlo va a ser desde un “viaje al pasado” sobre mi propia experiencia y cómo he descubierto yo el rol.

Espero que este post, además de ayudar a quien pudiera leerlo, me pueda servir también de guion para cuando todo esto acabe y me toque dar la charla de forma presencial 🙂

Lo primero que busca uno cuando quiere ser Scrum Master es la ‘Biblia del Scrum Master‘, un libro sagrado con todas las respuestas, prácticas y tipos de retrospectivas perfectamente detalladas y que te ayude en tu evangelización de Scrum.

Bueno pues spoiler, eso no existe. Y si existiese ya no estaríamos hablando ni de Scrum ni de agilidad, porque no nos estaríamos adaptando al entorno, sino a un libro.

Lo que sí existe, es la ya más que citada y re-citada en este blog, guía Scrum. En concreto yo empecé por la de 2017, que hoy por hoy sigue siendo la última versión.

A pesar de que la guía Scrum tiene solo 19 páginas (incluyendo portada e índice), le dedican ni más ni menos que una página entera al rol del Scrum Master, pivotando sobre 3 ejes (El Scrum Master al servicio del Product Owner, el Scrum Master al servicio del Development Team y el Scrum Master al servicio de la organización) [https://www.scrumguides.org/scrum-guide.html#team-sm]

Uno de los grandes errores que yo cometí fue leer e interiorizar esta guía después de llevar algunos años ya trabajando en equipos Scrum y ejerciendo de Scrum Master, y esto es una faena, porque te dificulta aprender a distinguir lo que es Scrum de lo que son prácticas, adaptaciones, o incluso disfunciones de un equipo ágil.

Y aquí está el problema. Si lees la guía, igual no detectas anti-patrones. No ves (ni piensas) que pueda haber algo que está afectando a tu agilidad porque, redoble de tambor, en una página de la guía no te da respuestas a absolutamente nada.

Así que, lo siguiente que hice, en mi búsqueda de respuestas, es irme a una versión anterior de la guía, la de 2016, pensando que, quizá, en la evolución del framework, habían eliminado definiciones concretas del rol que pudiesen no ajustarse a todos los contextos.

Bueno pues cual fue mi sorpresa al ver que en la guía de 2016 no hay más, sino MENOS información del Scrum Master. Si echamos un vistazo al ‘log’ de revisiones que ha tenido la guía, podemos encontrar este párrafo en la sección de 2016-2017:

  1. Changed wording in The Scrum Master section to provide better clarity to the role. The text now reads:
    The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
    The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
  2. Added to the section Scrum Master Service to the Product Owner
    Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.

https://www.scrumguides.org/revisions.html

En su momento no supe interpretarlo, pero como tiene que estar el tema para que, una guía donde revisión a revisión cada vez hay menos prescripciones para dar cabida a cualquier contexto, tengan que incluir una página entera para aportar “claridad al rol” (y soy consciente de que esto lo escribo mientras me estoy preparando una charla de quien es el Scrum Master en 30 minutos)

Bueno pues como de esa guía poco pude sacar, me fui a una versión anterior, de hecho, me fui a la primera guía Scrum oficial: la de 2010

Esta versión de la guía es mucho más prescriptiva, y da ‘respuestas’ o ‘sugerencias’ a temas con los que todavía hoy por hoy aún tenemos dudas sobre cómo abordarlos, como por ejemplo: ¿bajo qué criterios tengo que ordenar el Product Backlog? Si mis Sprints no duran un mes, sino menos ¿Qué time-box deben tener mis eventos (aunque en la versión de 2010 se les llamaba ceremonias)?

El problema de esto, como ya habréis imaginado, es que estas prescripciones no se adaptaban a las necesidades de todos los negocios ni de todos los equipos. Sin embargo, me resultó muy enriquecedor e interesante ver el punto de partida e intentar reflexionar sobre el porqué de las evoluciones de la guía.

Pero bueno ya que estaba metida en el bucle, pues seguí tirando hacia atrás y di con el primer Paper donde se presentó oficialmente Scrum, en la conferencia de OOPSLA de 1995.

Ay mi madre. Cada vez que leía metodología Scrum me entraba dolor de estómago. No se parece prácticamente en nada a lo que hoy conocemos de framework, pero, como en el caso anterior, su lectura me hizo reflexionar sobre de donde partió Scrum y cómo estamos ahora.

Y ya, por último, y por no perder la inercia, le di una lectura a ‘The New New Development Game’, de Takeuchi y Nonaka, de donde saqué ideas y conceptos que me parecieron muy interesantes. Parte de esta lectura, de hecho, me inspiró para una de las primeras entradas de este blog (https://www.deconstruyendoscrum.com/objetivos-que-nos-transciendan/)

Otra cosa que hice, fue leer el libro ‘Scrum: el arte de hacer el doble de trabajo en la mitad de tiempo’ de Jeff Sutherland (co-creador de Scrum) Y no os voy a engañar, lo compré convencida de que era un clickbait, me parecía imposible que Jeff Sutherland afirmase rotundamente que con Scrum podías hacer el doble en la mitad de tiempo (sobre todo porque yo llevaba ya como unas doscientas formaciones de ‘Introducciones a Agile’ donde contaba como falso mito que Agile es hacer lo mismo, pero más rápido) Pues para Jeff debo ser un chiste, porque ¡vaya que si lo afirmaba!

Como veis, aún no os he dado la respuesta, ¿Qué es un Scrum Master?

Yo he tenido que leer mucho, de mucha gente que sabe mucho más que yo y que lleva en esto muchos más años que yo, y he visto muchos videos, y escrito en foros, y me he cuestionado prácticamente todo lo que hago…

Y lo que yo he entendido que es un Scrum Master es:

El responsable de la eficiencia del proceso. O, dicho de otra forma, el encargado de eliminar el máximo desperdicio posible.

P.D: Por eso puedes hacer el doble en la mitad de tiempo, porque dejas de hacer cosas que no tienen valor 😉

Los roles en Scrum son los que son porque más roles generarían (normalmente) desperdicio: más interlocutores, lo que dificulta la comunicación; des-centralización de toma de decisiones; silos; etc… Lo mismo pasa con los eventos, con los artefactos y con cada una de las reglas de Scrum.

Así pues, vuestro (nuestro) deber como Scrum Master es encontrar desperdicio y ¡eliminarlo! Y, muy probablemente (que no siempre, dependerá del contexto), si estamos incumpliendo alguna regla de Scrum, estaremos generando desperdicio en el proceso.

¿Qué pensáis? ¿Me dará tiempo a contarlo en 30 minutos?

Y para vosotros… ¿Qué es un Scrum Master? ¡Os leo!

¡Feliz semana y salud para todos!

Master GIF by memecandy

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar