Derechos y deberes de los miembros de un equipo Scrum (o ágil en general, o de cualquier tipo)

Ya comentamos en su momento que el miedo es un peligro mayor que cualquier mala práctica de gestión software. Incluso Kent Beck en su Planning Extreme Programming (XP) decía que necesitamos un proceso software por la misma razón que necesitamos leyes: para evitar el miedo, para no perder nuestros “derechos”, para preservar la seguridad. Como cualquier comunidad o grupo, e igualmente en el software, una práctica típica para reducir el miedo es clarificar derechos y deberes.
Algo que me encuentro demasiadas veces en aquellos grupos que intentan aplicar Scrum, y que no les ha ido muy bien, es que conocen bien los nombres de los tres roles famosos de Scrum (Product Owner, Scrum Master y Equipo), pero ninguno de ellos tiene claro qué tiene que hacer. Y demasiadas cosas no las hace nadie, y demasiadas cosas las hace quien no debe.
Por ello, te dejo en este post una recopilación de derechos y deberes de cada uno de los tres roles típicos en Scrum.

Product Owner

Resumiendo (más información aquí claves para implantar el rol de Product Owner), un Product Owner es alguien que sabe lo que quieren los usuarios del sistema que se va a desarrollar, sabe priorizar y validar. Es quien aporta la visión de negocio al equipo. El Product Owner es el responsable de maximizar el valor que el equipo Scrum entrega al usuario. Para lograr esto, también es responsable de gestionar el Product Backlog.

Deberes

–        Recoger y tener claros los requisitos y necesidades de la aplicación.
–        Definir buenas historias de usuario.
–        Fijar criterios de aceptación para cada historia de usuario.
–        Ordenar y priorizar los ítems en el Product Backlog, en función del valor que aportan al usuario o cliente final.
–        Definir cuál es el producto mínimo viable.
–        Definir el plan de releases (o la visión estratégica).
–        Asegurarse de que el Product Backlog es visible para todo el mundo, y muestra cuáles son los siguientes ítems en los que tendrá que trabajar el equipo.
–        Asegurarse de que el equipo de desarrollo entiende claramente los ítems del Product Backlog.
–        Debe estar disponible y accesible para explicar al equipo técnico dudas que puedan surgir, validar entregas (en el Sprint Review) y participar en las reuniones (Daily meeting, si es necesario, y en el Sprint Planning Meeting, Sprint Review, Sprint Retrospective).
–        Acordar junto con el resto del equipo una definición del “DONE” (en un proyecto ágil, acordar una buena definición de lo que significa terminado, el done)
–        No debe dar órdenes al equipo de desarrollo. El equipo de desarrollo se auto gestionará, en base a las tareas que el Product Owner ha definido como prioritarias.
–        Además, es el responsable final de cancelar el sprint si la meta del sprint se queda obsoleta o de manera excepcional, se encuentran impedimentos muy graves para su realización.

Derechos

– Que el equipo de desarrollo no trabajé en otros requisitos distintos a los que el Product Owner incluya en el Backlog.

El equipo de desarrollo

Está formado por profesionales que trabajan para elaborar un incremento del producto, terminado y potencialmente entregable.

Deberes

–        El equipo debe ser auto-organizado. Los propios miembros del equipo establecerán la forma de hacer su trabajo.
–        Tiene que ser multifuncional.
–        Todos los miembros deben trabajar con sus habilidades para cumplir el sprint goal.
–        Los equipos de desarrollo deben ser pequeños, de 3 -7 personas.
–        Junto con el Scrum Master, se encargan de establecer los ítems del Sprint Backlog, de planificar el sprint.
–        Estimar las historias de usuario y tareas.
–        Hacer la demo.
–        Implementar pruebas de aceptación y pruebas unitarias.
–        Trabajo de calidad y mejora continua de la calidad (refactorización, por ejemplo)
–        Participar en los Daily meeting, Sprint Planning Meeting, Sprint Review y Sprint Retrospective.
–        Estar motivados.
–        Saber buenas prácticas de programación: pair programming, TDD, integración continua, refactorización, malos olores, patrones de diseño, etc.
–        Identificar posibles obstáculos y comunicárselos al Scrum Master.
–        Actualizar el trabajo en progreso (burndown chart) (es responsabilidad tanto del equipo de desarrollo como del Scrum Master)

Derechos

–        La organización tiene que animar al equipo a auto-organizarse, sin entrometerse en su forma de trabajar.
–        A que solo bajo contadas y controladas circunstancias, las tareas del sprint sean modificadas una vez que este ha comenzado.

El Scrum Master

Mientras que el Product Owner se centra en el valor y tiene la visión de negocio, el Scrum Master se centra en el proceso Scrum, actúa como mentor y ayuda a resolver los impedimentos que vayan surgiendo. Es el responsable de asegurarse de que todo el equipo entiende Scrum y actúa en consecuencia a su teoría, prácticas y reglas.
El Scrum Master debe ayudar a la gente que está fuera del equipo Scrum a entender qué interacciones con el equipo son positivas y aportan valor al equipo y cuáles no.
Debe ayudar también a toda la organización, a entender e implantar Scrum, planificando la implantación de Scrum junto con la organización.
El Scrum Master sirve al Product Owner:
–        Ayudándole a entender la agilidad.
–        Enseñándole técnicas para gestionar efectivamente el Product Backlog y maximizar el valor de negocio.
En cuanto al equipo de desarrollo, el Scrum Master ayuda a:
–        Que entiendan los ítems del Product Backlog
–        Auto-organizarse y convertirse en equipos multifuncionales
–        Crear productos que aporten valor al cliente o usuario
–        Eliminar los problemas que impidan progresar al equipo de desarrollo.
Otros deberes:
–        Participar en las reuniones de Scrum, asegurarse de que duren el tiempo establecido y cumplan su objetivo (Daily meeting, Sprint Planning Meeting, Sprint Review, Sprint Retrospective).
De forma general, si es necesario, el Scrum Master puede realizar cursos de formación o eventos sobre Scrum, para el Product Owner, el equipo de desarrollo o incluso la organización entera. También debe colaborar y trabajar con otros Scrum Masters para encontrar formas de mejorar la implantación de Scrum en la organización.

¿Echais algo en falta?

2 comentarios en “Derechos y deberes de los miembros de un equipo Scrum (o ágil en general, o de cualquier tipo)”

  1. Muchas gracias, por el post. Solo tengo una pregunta, en los deberes del equipo de desarrollo indica: Esta motivados. Esto no es tambien algo que el Scrum Master debe colaborar, creando o ayudando a crear un ambiente tal, que el equipo se motive?
    gracias.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba