Roles de Scrum definidos
Hago mucho trabajo con Scrum y los proyectos que más problemas presentan aquellos en los que los roles de Scrum están mal definidos y/o no ocupados correctamente. Scrum es un marco equilibrado y cuando los papeles no se distinguen suficientemente, el marco comienza a adoptar las disfunciones de la organización y no es tan poderoso como podría ser.
En Scrum hay tres roles- miembro del equipo, Product Owner y ScrumMaster. Cuando los tres trabajan juntos son llamados el Equipo Scrum (o simplemente el equipo). Añado un cuarto papel – Stakeholder – para reconocer a todas las personas que orbitan en un Equipo Scrum e influyen en el. Defino todos estos papeles a como sigue:
Equipo: dedicada colección de individuos auto-organizados, interdependientes y que comparten una localización, que representan diferentes roles funcionales con todas las competencias necesarias para convertir elementos del Product Backlog del producto en un incremento potencialmente entregable en el Sprint.
Product Owner: persona facultada para aplicar su juicio personal y profesional para tomar decisiones en el mejor interés de diferentes, muchas veces en competencia, Stakeholders del negocio para maximizar el valor de negocio que el equipo produce cada Sprint
Scrum Master: persona dedicada responsable de mejorar el rendimiento del equipo y el negocio por cualquier medio necesario.
Stakeholder: cualquier persona que tenga un interés, directo o indirecto, en el trabajo del Equipo.
Tenga en cuenta, estas son definiciones de roles, no descripciones de trabajo a seguir y que están muy vagamente definidas. Es importante que cada papel esté completo. En general, el Product Owner se concentra en los resultados que proporcionan valor para el negocio, mientras que el ScrumMaster apunta su/sus esfuerzos en la ejecución de un buen Scrum y mejorar el flujo de valor para el cliente. Mientras tanto, el equipo permanece centrado en aprender a auto-organizarse y ofrecer incrementos potencialmente entregables regularmente. Los Stakeholders ofrecen información sobre el valor de los esfuerzos de todos.
Cuando Scrum se tambalea, a menudo es porque la gente no se están comprometiendo en sus roles. Otras veces, las organizaciones optaron por sobrecargar uno o más roles en una sola persona, lo que altera el equilibrio de los roles. Recordemos, el marco Scrum fue diseñado para proporcionar la máxima flexibilidad con la cantidad mínima de control. Si estas funciones no se pueden llevar a cabo con los individuos asignados plenamente a ellas, o que tienen sobrecarga, los mecanismos de control de Scrum se convierten se descontrolan, la visibilidad se ve disminuida, la rendición de cuentas se pierde y el marco pierde su significado.
Cuando Scrum se hace bien, existe una tensión natural entre cada rol. Esta tensión ejerce una fuerza que tiende a impedir que los otros roles se inmiscuyan en las responsabilidades que no son suyas. Puesto que hay considerables áreas grises en los límites de conducta en Scrum, cada rol eventualmente choca con otros a medida que descubren cuáles son los límites de sus responsabilidades. Esta fricción es una parte esencial del aprendizaje de cómo hacer Scrum y hacerlo significativo para su negocio. A través del proceso de inspeccionar-y-adaptar, la definición precisa de cada función – miembros del equipo, Product Owner, Scrum Master y de los Stakeholders – emerge a la vez que su organización gana experiencia usando Scrum.
Una de las principales razones por las que agrego un rol de Stakeholder a Scrum es porque muchas implementaciones de Scrum se mantiene a los Stakeholders indebidamente fuera del proceso a estas personas. Scrum no fue diseñado para mantener a los Stakeholders fuera de interacción con el Equipo. De hecho, Scrum fue diseñado para traer a esta gente más cerca. Lo que Scrum intenta hacer es dar a los Stakeholders un papel más significativo, estructurado para interactuar y proporcionar al equipo comentarios a través de la revisión del Sprint. Esta es la oportunidad para que el equipo pueda escuchar, retroalimentación directa sin adornos sobre lo que realmente piensan. Esta es la razón por los Stakeholders tienen una línea discontinua conectando a sí mismos con el equipo, en lugar de una línea continua.
