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.
