Los roles de Scrum

Cuando se trata de Scrum como un marco ágil para el desarrollo de software, los roles son importantes. Los roles del Product Manager, Scrum Master y el equipo de desarrollo son tan importantes que fusionarlos podría llevar a la interrupción del trabajo del equipo y a la incapacidad de completar un proyecto a tiempo, o al menos eso es lo que dicen los principios de Scrum.

Pero vivimos en el mundo real con equipos pequeños, presupuestos ajustados, y jefes de proyectos y clientes malhumorados. No siempre es fácil seguir los principios de una metodología. A veces, se deben combinar los roles.

Entonces, cuando se hace un proyecto con Scrum ¿se deben seguir los principios de Scrum y nunca mezclar roles? ¿O hay ocasiones en que la combinación de dos roles podría ser beneficiosa para un equipo de Scrum?

Hay 3 roles principales en Scrum: el producto owner, el Scrum Master y el equipo de desarrollo. Estas funciones hacen que el desarrollo del software sean lo más eficientes posible para satisfacer al cliente.

Aquí un rápido resumen de los roles y sus responsabilidades:

Product Owner

El producto Owner tiene la visión del producto y su producción. Es la voz del cliente y la representación de los stakeholders, por tanto, opera desde un punto de vista comercial, creando y comprendiendo las historias de usuario, agregándolas a producto backlog y priorizando las tareas que proporcionarán el mayor valor al cliente y a las partes interesadas.

Scrum Master

El Scrum Master es a la vez un entrenador, un facilitador y un moderador. Tiene dos responsabilidades principales: primero, protege el scrum y despeja el camino de los impedimentos, como obstáculos y distracciones, para el equipo de desarrollo; en segundo lugar, utiliza su profundo conocimiento de los principios de Scrum para asegurarse de que el equipo sigue la metodología. Otras responsabilidades de un Scrum Master pueden incluir mantener abiertos los canales de comunicación entre el equipo, protegiéndolo de interferencias externas, obstáculos o distracciones.

Equipo de desarrollo

El equipo de desarrollo está formado por un puñado de personas (normalmente entre 3 y 9 personas, sin incluir el Product Owner y Scrum Master), que crean el producto mediante el análisis, el desarrollo, el diseño, las pruebas y la documentación. Se autogestionan y se autoorganizan, lo que significa que deciden cómo realizar las tareas y cómo lograr los objetivos. Ellos son responsables de sí mismos cuando construyen el proyecto y lo hacen con la ayuda del Product Owner y Scrum Master.

Si el equipo pequeño, es posible que se deban combinar roles por necesidad. A continuación, algunas combinaciones y sus consecuencias:

PRODUCT OWNER + EQUIPO DE DESARROLLO

Es peligroso cuando el Product Owner también quiere participar en el proceso de desarrollo. Si lo hiciera, comenzaría a pensar demasiado en cómo se lograrán las cosas cuando debería pensar en lo que debe lograrse y por qué, y cuál es el valor comercial de hacerlo. El Product Owner debe estar fuera del equipo de desarrollo, ya que, de lo contrario, se presentaría un conflicto de intereses.

 SCRUM MASTER + PRODUCT OWNER

Como dijimos antes, el Product Owner trabaja desde la perspectiva del usuario final y el cliente, con el objetivo de entregar el mayor valor y que se construya lo correcto. El Scrum Master es parte del equipo técnico y busca que se cumpla el proceso y eliminar problemas.

Las principales diferencias son la mentalidad externa del PO (hacia el cliente y stakeholders), y la interna del SM (hacia el equipo); el PO está más enfocado hacia el qué y el cómo, y el SM hacia el cómo, y las principales excepciones del PO son los cambios de alcance y del SM los impedimentos generales

Desempeñar los roles de Scrum Master y Product Manager puede funcionar en el sentido de poder administrar bien la planificación del Sprint sabiendo cómo se quiere que evolucione el producto, aunque quien desempeñe ambos roles en la reunión de planificación de sprint estará a caballo entre negocio y equipo frente a un equipo unilateral.

Como en el daily meeting el rol es exclusivamente de Scrum Master, no habría conflicto entre los dos roles. Tampoco en el sprint review ya que, aunque pudiera haber imparcialidad, no puede haber influencia retroactiva.

Sin embargo, en un Refinamiento, ¿cómo vas a ser capaz de defender tu postura como cliente por un lado y como facilitador por otro?, ¿quién te corregirá cuando, como propietario, realices acciones inapropiadas para Scrum?, ¿serás capaz de establecer un protocolo para que el equipo de desarrollo identifique qué rol juegas cuando estás hablando?

Uno de los beneficios de combinar ambos roles sería que el Product Owner tendría la ocasión de acercarse al equipo y obtener una visión desde dentro, lo cual daría lugar a un aprendizaje por ambas partes y una integración más fuerte.

Sin embargo, Product Owner y Scrum Master son roles son antagónicos por definición. Sirven a diferentes personas, el cliente y los stakeholders frente a los miembros del equipo de desarrollo, respectivamente. El conflicto es que el objetivo del Scrum Master es defender y administrar el proceso, por lo que esto incluye proteger al equipo de las demandas de los stakeholders. El Scrum Master quiere el mejor equipo y el Product Owner quiere el mejor producto.

El Scrum Master vela para que Scrum se aplique correctamente y se asegura de que el equipo esté motivado y focalizado en sus tareas, y de que nada ni nadie interfiera en el Sprint. El Product Owner hace justamente lo contrario. Dado que su objetivo es absorber el cambio que se produce en el negocio y mantener un producto backlog cambiante, interrumpe e interfiere en el equipo por naturaleza. Desempeñando ambos roles es difícil resistirse a esa tentación.

Permitir que alguien sea tanto el Scrum Master como el Product Owner puede eliminar la tensión beneficiosa del segundo que puede pedir más de lo que el equipo puede dar

Un Product Owner y un Scrum Master fusionado puede dedicar más tiempo a defender el producto que a eliminar obstáculos o a facilitar conversaciones para el equipo.

El objetivo del Product Owner es obtener el mejor producto posible en el menor tiempo posible, por tanto, el Product Owner podría pedirle al equipo que hiciera cosas que podrían interrumpir y dañar el proceso, el equipo o el producto. El conflicto de defender el proceso y defender el producto tiene un conflicto inherente.

Si un Scrum Master adopta también el rol de Product Owner, tenderá más hacia la parte técnica y dejará de lado más a menudo las decisiones de negocio, y viceversa, es decir, si predomina el Scrum Master y no hay nadie estirando hacia el negocio, el resultado puede ser un enfoque más tecnológico de lo debido o marcado por el ritmo del equipo. Si por el contrario, predomina el Product Owner puede ocurrir que éste acabe dirigiendo el equipo de desarrollo.

Aunque no sea recomendable, si no hubiera posibilidad de un Scrum Master dedicado, habría que asegurarse de aislar los dos modos de pensar y actuar (SM y PO, respectivamente).

SCRUM MASTER + EQUIPO DE DESARROLLO + PRODUCT OWNER

Si el Product Owner es Scrum Master y, a veces, parte del equipo de desarrollo, es posible que tenga más trabajo del que pueda manejar y que deban delegar esas tareas a otros miembros del equipo. Esto, a veces, puede causar un conflicto de intereses

SCRUM MASTER + EQUIPO DE DESARROLLO

El Scrum Master es un papel, no tanto una persona. Si un equipo es completamente auto-organizado, el rol del Scrum Master se podría integrar en el equipo. El Scrum Master podría contribuir en el proceso de desarrollo cuando el equipo lo necesita, pero como mantenedor imparcial del proceso Scrum, debería abstenerse de estimar tareas.

El Scrum Master pues, podría ser un desarrollador, ya que en este caso no existe un conflicto de intereses tan grave, o que un miembro del equipo a veces se convirtiera en facilitador. El reto sería no perder el foco. El Scrum Master, al estar involucrado en el proyecto, podría verse condicionado en sus decisiones como tal. Debería velar por la forma en que se trabaja y que el equipo esté “sano” y sea productivo a la vez que formar parte del mismo e intervenir directamente en decisiones sobre el producto.

Sin embargo, alguien que realice el rol de Scrum Master y miembro del equipo necesita ser altamente sociable. El equipo necesita sentirse cómodo al tener discusiones porque requerirá enseñanza, tutoría, entrenamiento y facilitación. El equipo también necesita confiar en esa persona, por lo que las habilidades sociales serán imprescindibles para que eso suceda. El segundo atributo es la experiencia técnica. La persona que asuma ambos roles debe tener un alto nivel de habilidades técnicas para poder solucionar problemas con el equipo y poder tener una visión de los sistemas. Esencialmente, necesita poder hablar el mismo idioma que el equipo.

El Scrum Master debe ser un líder servidor y podría ser un miembro del equipo. El Scrum Master podría estar en las trincheras, realizando las tareas que se le dan mejor: puede ser un programador, un tester, un analista o cualquier otro rol que su equipo de scrum incluya.

No obstante, como las habilidades de liderazgo para un Scrum Master son imprescindibles, combinar ambos roles no debería ser un enfoque a largo plazo (más de un año, por ejemplo). En algún momento, la persona debería convertirse en Scrum Master a tiempo completo o participar como miembro de equipo a tiempo completo.

Por otro lado, parece difícil realizar una retrospectiva como Scrum Master y participar en ella como desarrollador. En tal caso también existe un problema de independencia.

Además, cuando más se necesita el Scrum Master, más se necesita la capacidad de desarrollo. Cuando el proyecto tuviera problemas, el desarrollo iría al 120% y nadie está allí porque el Scrum Master se habría sacrificado por el 120% del desarrollo.

Cuando permitimos el rol múltiple de una persona en el grupo, comenzamos a erosionar aquellas cosas que hacen que el trabajo sea ágil. Agotamos los mecanismos que impulsan la eficiencia y la eficacia. Los miembros del equipo implícitamente han otorgado unos valores y ámbitos de credibilidad a cada rol y a cada persona. Es mejor elegir un rol y comunicarse de esa manera.