Los roles específicos en Scrum, Scrum Master y Propietarios de producto, una sola persona con ambos roles, eso no es ágil

Siempre se dice que los equipos ágiles deben ser auto gestionados y  multidisciplinares. ¿Qué significa eso? Significa que tienen que tener la suficiente capacidad de gestión para poder realizar las funciones oportunas para la consecución del sprint o iteración correctamente, y que si tienen que trabajar en varias áreas o conocimientos deben tener esa capacidad de adaptación.

Esto muchas veces desde las gerencias empresariales se vuelve en contra, de la empresa y del equipo.  ¿Cómo? Tratando de asumir varios roles a la vez por la misma persona, somos más productivos, reducimos costes (1 persona = 2 roles = 2 personas). Es que son equipos multidisciplinares... Y ahí surge el problema.

El Scrum Master es desarrollador también del equipo, 50% desarrollo, 50% Scrum Master, el Scrum Master y el Product Owner son la misma persona. ¡Somos equipos multidisciplinares!  ..¡MAL!  Muchas veces las personas  se presentan como responsable de producto y Scrum Master, Proyect Manager y Scrum Master. Está bien que tengan ambos conocimientos, le facilitará su labor, pero por el bien de los equipos, que no se ejerzan ambos roles a la vez, Product Owner y Scrum Master.

Jeff Sutherland y Ken Schwaber, padres e inventores de Scrum,  ya decían en la década de los 90 y siguen diciéndolo en el siglo XXI que los roles son específicos, ¿Porqué? Por productividad. Una persona es mucho más productiva si no tiene cambios de contexto y se dedica a una función.

El Product  Owner muchas veces viene de ser Jefe de Proyecto, Proyect Manager, etc. Con experiencia y un control total del proyecto, de las personas y del proceso. Un buen Jefe de Proyecto, se puede reconvertir en Product Owner o en Scrum Master si tiene amplios conocimientos de la metodología, o se encarga del producto o del proceso para llegar al producto, pero no de ambos, el Scrum Master velará para que se dedique a hacer sus funciones, pero nunca será ambos roles a la vez, ese es un mal endémico del pasado, de los proyecto no ágiles, el CONTROL absoluto del proyecto.  Si el agilismo dice  girar en torno a equipos auto gestionados y multidisciplinares, hagamos que sea verdad.

El Product Owner es responsable del producto, de que salga adelante, de priorizar, eliminar y crear elementos del backlog que aporten valor al producto final, de reunirse con el equipo, para que este entienda que debe de realizar y en qué debe de centrar sus esfuerzos, reunirse con clientes que tienen visión o aportan ideas al producto y mostrar los avances. Bastante trabajo es ese ya, no lo sobrecarguemos con más.

El Scrum Master es un líder servicial, que debería de conocer las metodologías ágiles y Scrum en particular, y que vela para que el equipo adopte esas pautas y elimina los impedimentos que puedan surgir en el seno del equipo. Se puede, para equipos pequeños, si el equipo tiene conocimientos de Scrum, compartir el rol de miembro del equipo (ejerciendo funciones de desarrollo del producto) y Scrum Master, pero si no se tiene conocimiento en metodologías ágiles en el equipo ó si el equipo tiene 4 o más miembros, el Scrum Master deberá ser 100 % líder servicial del proceso Scrum. El Scrum Master puede entrar en conflicto si es miembro comprometido del equipo, puesto que tendrá que elegir entre realizar las tareas del Sprint o eliminar los obstáculos que aparecen durante le Sprint (incluido su propio obstáculo de no ser tan productivo al compartir roles y responsabilidades). Bastante trabajo es ese ya, no lo sobrecarguemos con más.

 ¿Porqué? Por productividad, evitaremos cambios de contextos y mejoraremos el equipo, lo convertiremos en 100% ágil, y lo que es más importante, ese Scrum Master podrá dedicarse a adquirir conocimientos, inspeccionar y probar técnicas en el equipo, nuevos métodos que lo hagan más productivo, más ágil al equipo. El Scrum Master trabaja con clientes y gerencia para identificar y nombrar al Propietario del Producto si hace falta, explica al Propietario del Producto como hacer su trabajo, como gestionar, y optimizar el valor del producto,  trata de sacar lo mejor del equipo convirtiéndolo en ágil y elimina todos los impedimentos que surjan en el equipo.

Los grandes gurús del agilismo, Jeff Sutherland,  Ken Schwaber, Mike Beadle, Martine Devos, Mike Cohn dicen algo muy importante, se recorre un camino para ser ágiles, pero o se es ágil al 100% o no se es ágil. Nos engañamos diciendo somos ágiles al 70%, o somos ágiles,  hacemos iteraciones, dailys, pero no hacemos retrospectivas. Seremos ágiles cuando veamos equipos productivos, comprometidos, evolucionados en el tiempo y con ansias de mejora cada día en el trabajo, 100% ágiles, cuando incluso, al Scrum Master, le cueste trabajo el conseguir mejoras en el equipo, porque dicho equipo roce la excelencia ágil. Eso es ser ágil.