Siempre se habla de quien Scrum existen tres roles: Scrum Master, Produjo Owner y Developers. Hace años que esta figura fue eliminada en pos de un nuevo concepto llamado responsabilidades o accountabilities. Sin embargo muchos artículos y libros hablan de los roles de Scrum… ¿nos están engañando,?
Esto es mío
Hace años que trabajaba en una empresa en la que dirigía un equipo de calidad. Este equipo sentía que en ciertos momentos se les ignoraba y me pedían que impusiéramos algún sistema en el cual todas las pruebas de la compañía pasarán por el área. De alguna manera reclamaban darle mayor importancia a este rol y hacer que rezo a la compañía se apoyara en él para obtener el resultado.
El dilema con esta estrategia es que si cada área pone sobre la mesa reglas generamos una burocracia excesiva a la hora de entregar valor. Por ejemplo esta tarea que me han pedido urgente la tiene que validar pues una persona de calidad o la tiene que hacer un front o quién la hace. Si tenemos que estar continuamente preguntándonos cómo abordar una tarea debido a las reglas que hemos impuesto cada uno de los roles acabaremos mareando y retrasando mucho la entrega de valor y por tanto nuestra capacidad de aprovechar oportunidades de mercado.
Sin embargo, esta petición de los equipos de calidad lo he visto muchas veces con más perfiles: sistemas, analistas, UX etc. Roles que intentan situarse y tener un espacio dentro de las empresas.
Una empresa por rol
En la mayoría de organizaciones se utilizan matrices de roles y responsabilidades. Definimos todos los roles de nuestra compañía y les atribuímos a cada uno de ellos diferentes tareas de las que se tienen que hacer responsables.
Esta estrategia tiene varios impedimentos, entre ellos, que generamos una cultura de fortificación, con comportamientos del estadillo “esto es mío y nadie lo toca”. Además de que el tener roles definidos suele generar roces cuando cada uno de ellos tiene un responsable. Muchas veces se generan debates entre el responsable front y responsable de back sobre la visión del equipo. Si a esto le sumamos que cada área funcional dispone de prioridades distintas generamos un caldo de cultivo para la discusión continúa.
Las organizaciones basadas en roles (o funciones) son muy habituales porque se considera que de esta forma ahorramos costes. La realidad es que aumentamos la burocracia y la tensión dentro de los equipos y podemos tener problemas a la hora de la entrega valor. He trabajado con muchos equipos con un ambiente muy sano que funciona solo que cuesta mucho más engrasar a un equipo cuando cada persona tiene su propio rol.
Alternativa a los roles
Una de las propuestas de Scrum es eliminar el concepto rol en post del concepto de habilidad (skill en inglés). Las personas abandonan su rol y se muestran como un conjunto de responsabilidades de las que se van a encargar además de un conjunto de habilidades que tienen. La gracia de un equipo que funciona es que eliminamos las etiquetas y nos centramos en sacar el problema adelante porque nadie está etiquetado. Dejan de existir por tanto los front, back, arquitectos, Qa o UX. Ahora somos compañeros que juntos tenemos un propósito y cada uno de nosotros pone encima de la mesa sus habilidades para el bien del equipo.
Si has crecido con la serie Dragones y Mazmorras recordarás que cada compañero tenía un poder que ponía el servicio del grupo para resolver los diferentes retos que se les presentaban. Eliminar etiquetas es muy positivo porque elimina bastante ego y deja claro a las personas que lo importante es lo que saben hacer y no quién eres.
LinkedIn no ayuda
Está claro que vivimos en el mundo de las etiquetas. Redes sociales como LinkedIn lo primero que hacen es mostrarte la etiqueta o rol que una persona tiene en vez de sus habilidades. Las habilidades se ubican en la última sección, al fondo del perfil. A la hora de simplificar siempre nos gusta etiquetar incluso lo hacemos a nivel político: eres rojo, eres facha, eres…
Está muy instaurada en las empresas las etiquetas porque ayudan muchísimo a simplificar los perfiles. Es más sencillo decir que María es QA-Junior en vez de decir María domina muy bien estas tres habilidades y tiene que mejorar en estas cuatro.
Scrum y los roles
Scrum decidió eliminar los roles para mejorar la integración de los equipos. también eliminó el concepto de Development Team, precisamente para que el foco de todos los equipos Scrum fuera el propio Scrum Team, que gana relevancia en el Scrum actual. Es decir, la autogestión que propone Scrum funciona si nos olvidamos de nuestros roles y nos centramos en resolver el problema juntos, como equipo (Scrum Team). Un equipo unido con responsabilidades compartidas y que lucha por un propósito funcionará más rápido y mejor que uno cargado de etiquetas
Y si te estás preguntando qué hace entonces el Scrum Master o el Product Owner, . Scrum lo soluciona añadiendo el concepto de accountability. En los equipos hay personas que deben de asumir el accountability del Scrum Master o del Product Owner. Estas responsabilidades sirven para que quede claro qué elementos necesita un equipo para funcionar. Por ejemplo, necesitamos que alguien trabaje con la organización para entender lo que supone trabajar en entornos empíricos con complejidad, Y también necesitamos a alguien que se encargue de las prioridades y de marcar que es lo que podría darnos valor. Pero dejamos de pensar en roles.
Por eso, cuando veas infografías o cursos hablando de “los roles de Scrum” sospecha que, probablemente, te están engañando.
Y tú ¿sigues usando los roles de Scrum?
