¿Quién es quién con los roles de Scrum?

Hace poco estuve en una Transformación de una gran empresa ayudando a varios equipos a hacer Scrum. La primera dificultad que me encontré era la definición de los roles. Estábamos en un proceso de transformación y nos estaba costando mucho identificar los diferentes roles que íbamos a utilizar: Product Owner, Development Team y Scrum Master.

Es bastante habitual en las transformaciones usar Scrum como marco de trabajo base para todos los equipos. Scrum tiene una dificultad, necesita de nuevos roles que no existen en la empresa, con los problemas que esto genera: falta de identidad, desconocimiento de las nuevas labores, cambio de mindset, nuevas carreras profesionales, nuevas habilidades…  Recordemos que, en Scrum, los roles son los que inspeccionan y adaptan los diferentes artefactos en los eventos. Por tanto, a la hora de empezar con un nuevo equipo tenemos que identificar cada uno de los roles. 

Recordar el “accountability” de los roles de Scrum

En inglés, la palabra “responsable” se puede traducir por dos palabras diferentes: accountable y responsible. La primera de ellas, se traduciría por “el que rinde cuentas”, es decir, la persona que en último lugar tendría que responder o dar una explicación. Por ejemplo, si el Product Owner debe definir lo que se va a hacer (Accountable) y deja que el Development Team decida (Responsible) en caso de que salga mal, será el Product Owner el que deba responder ante la organización. 

Para poder transformar un equipo y, a su vez, una organización, debemos dejar muy claro la responsabilidad de cada rol. Por eso, en mi caso, suelo hacer una formación nada más llegar a un nuevo equipo u organización. Tener una conversación sobre cada rol, antes de empezar a trabajar, nos facilita el trabajo cuando practicamos los eventos. 

Recordar a cada rol su responsabilidad no es lo mismo que exigir. Para poder “exigir”, es importante que cada rol tenga libertad en la toma de decisiones. Decirle a un Development Team que ha actuado mal porque no ha entregado incremento en el Sprint, cuando no tiene las herramientas adecuadas y no puede tomar ninguna decisión, es difícil. Aquí es donde empieza la famosa “transformación de la empresa”. Un Scrum Master explica al resto de su equipo sus responsabilidades y también lo hace con la propia empresa para que dejen a los equipos tomar decisiones. Las personas solo son responsables de las decisiones que toman. 

Imagina un equipo al que le dicen que va a hacer Scrum, pero que en tres meses tiene que entregar una serie de features urgentes. Añade que la tecnología la impone el cliente, el equipo no ha podido decidir ni opinar y, encima, no ha podido autocomponerse para abordar el problema. Además, al Product Owner le entregan un documento con todos los requisitos y las fechas. Finalmente, el software tiene muchas dependencias de equipos con los que cuesta comunicarse. ¿De verdad podemos pedir responsabilidad ante esta situación? 

Nadie quiere ser Product Owner

La figura del Product Owner es vital para que funciona Scrum. Este rol vela por el negocio y por maximizar el valor del trabajo. En muchas empresas, ocupan este puesto personas con una posición jerárquica. 

Uno de los grandes retos es disponer de un Product Owner a tiempo completo. Es habitual que las personas que pueden ejercer este rol con garantías estén atendiendo a varios equipos a la vez.  Sí optamos por un manager jerárquico, con poder de decisión, seguramente no vea con buenos ojos el participar como Product Owner ya que lo puede sentir como una degradación de funciones. 

Recordemos que para pasar de un modelo Proyecto a Producto, el Product Owner debe disponer de cierta capacidad de decisión lo que altera las estructuras de poder de la empresa. Por ejemplo, ¿quién es el encargado de ponerle precio a la aplicación? Un Product Owner podría hacerlo pero quizás no tenga experiencia en eso y lleva tiempo adquirir ese conocimiento.  

Development  Team es más difícil de lo que crees

El Development Team parece el rol más fácil de conseguir ya que, en las organizaciones tradicionales, teníamos equipos de desarrollo antes de que llegara Scrum. Sin embargo, un Development Team tiene ciertas características que requieren de una transformación de la empresa. Por ejemplo, tenemos que tener equipos multidisciplinares lo que supone romper silos históricos. Además, eliminamos las etiquetas del equipo, lo que afecta a las carreras profesionales que se han definido desde Recursos Humanos. También cambiamos  la medición individual por una grupal, orientada al valor, lo que contradice las métricas tradicionales que hemos usado hasta ahora. Además, el equipo se autoorganiza, lo que supone dejarles tomar decisiones. Si no están entrenados en la autoorganización, va a llevar tiempo que funcione. A todo esto, hay que sumarle nuevas prácticas de desarrollo como pair programming o test driven development (TDD), lo que supone un cambio importante en la manera de concebir el software. 

Por tanto, disponer de Development Team capaces de entregar valor de manera contínua y capaces de interiorizar los valores de Scrum lleva bastante tiempo y requiere de mucho trabajo. 

El Scrum Master no hace nada

Respecto a Scrum Master ya hemos repasado muchas de sus funciones y de para qué necesitamos uno. Es verdad que un Scrum Master enseña al resto de su equipo a trabajar en Scrum. No obstante, el gran reto es enseñar a la organización a hacerlo y aquí está el gran reto para este rol. Muy pocos Scrum Master están preparados o entienden que sea su función. 

Un Scrum Master maduro tendrá un panel de impedimentos con los que transparentar todas los stoppers que impiden una entrega de valor. Me gusta mucho la visión de Tobías Mayer sobre el Scrum Master: un Scrum Master es como una avispa frente a un tren (la empresa). No puedes parar el tren, pero si puedes pinchar al maquinista. 

Un Scrum Master que se enfoca en la entrega de valor deberá trabajar con la organización para implantar los cambios necesarios para conseguirlo. 

Kanban nos lleva ventaja

Kanban no prescribe roles de ningún tipo lo que es una ventaja porque es menos disruptivo a la hora de implantarlo en una organización. Es cierto que Kanban propone un par de roles similares al Product Owner y al Scrum Master. Pero, no es obligatorio, ya que Kanban se centra  mucho en visualizar el trabajo y en arrancar desde donde estés para introducir la mejora continua poco a poco. Por eso, en organizaciones donde sea difícil introducir Scrum, quizás el método Kanban sea la mejor alternativa.

En Kanban tratamos de que el trabajo fluya y no creamos roles para que eso ocurra, solo medimos dicha fluidez y picamos a la empresa para que se remangue para conseguirlo. Obviamente, para que el trabajo fluya habrá que introducir muchos cambios en la organización, pero eso ocurrirá en base a datos y no siendo tan disruptivo. 

¿Quién es quién? (Los roles de Scrum)

Os quería compartir una dinámica llamada “quién es quién” y que sirve para aclarar las responsabilidades de cada rol. La dinámica es simple, dividimos a las personas en grupos de 3-4 miembros. A cada grupo le repartimos tarjetas con diferentes labores y les dejamos que decidan quién es el “accountable” de cada labor. Podemos dar puntuación con los aciertos para gamificar la dinámica. Tras terminar de ordenar las labores, tenemos un debate sobre estas funciones, con lo que podemos alinearnos todos en las funciones de cada rol. 

Si quieres una copia de esta dinámica, escríbenos a este link y te la compartimos. 

Por tanto, como Scrum Master, lo primero que debemos hacer es fijar bien los roles y responsabilidades, para después empezar a tener los eventos y artefactos que nos permitan la entrega de valor. 

Y tú, ¿cómo implantas los roles de Scrum?