El Product Owner

El Product Owner es uno de los tres roles que se pueden encontrar en Agile.

El Product Owner es el responsable de definir las Historias de Usuario (User Stories) y priorizar el backlog del team. Su papel principal es maximizar el valor producido por el equipo y asegurar que las historias que se crean satisfacen las necesidades del usuario y cumplen la Definición de Hecho (Definition of Done, DoD).

El Product Owner es el punto de contacto entre el cliente y el equipo y debe tener una relación muy estrecha con Product Management y otros stakeholders (incluyendo otros Product Owners), con el objetivo de poder definir y priorizar las historias de usuario en el backlog del equipo.

Veamos algunas de las responsabilidades del Product Owner:

• Actualizar y mantener el backlog antes de la planificación de las iteraciones. El Product Owner tiene un diálogo constante con los clientes y stakeholders para conocer sus necesidades y las del negocio, y antes de la reunión de planificación de la iteracion, el Product Owner debe actualizar el backlog del equipo incluyendo nuevas historias que hayan aparecido, eliminando otras que ya no tengan sentido (o reduciendo considerablemente su prioridad), y debe actualizar la prioridad de todas ellas según unos criterios concretos. El backlog también incluye mejoras, refactoring, etc. y el Product Owner es el responsable de priorizar todos los elementos, basándose en el valor para el usuario, el tiempo, y posibles dependencias con otros teams o productos.
• Participar en la planificación de las iteraciones.  Durante el evento de planificación, es el responsable de que las historias de usuario que se van a abordar en la iteración estén claras para el equipo y ayuda a definir el objetivo de la iteración que se está planificando. También es responsable de coordinar las dependencias con otros Product Owners. Durante la planificaciión se encarga de que el equipo esté alineado y lleguen a un acuerdo sobre el objetivo y resultado finales de la iteración.
• Aceptar las historias. El product Owner trabaja con el equipo para aceptar las historias completadas. Esto incluye validar que dichas historias cumplen los criterios de aceptación (Acceptance Criteria), que incluye los test necesarios para ser aceptada y que cumple con la Definicion de Hecho (Definition of Done) de cada historia. De este modo el Product Owner asegura el nivel de calidad de las entregas del equipo.
• Participar en la Revisión. El Product Owner colabora con el team y con cualquier otro stakeholder involucrado e interesado en la revisión de los resultados que el equipo entrega en esa iteración.
• Participar en la Retrospectiva. El Product Owner es un miembro más del equipo a la hora de Inpeccionar y Adaptar, y la retrospectiva es un claro exponente de esta parte del proceso de evolución del team. Durante esta retrospectiva pueden aparecer ideas de mejora del producto y el Product Owner debe estar involucrado en las discusiones para conocer el alcance y el impacto de esas mejoras y de ese modo tener la capacidad de incluirlas en el backlog y priorizarlas.

Si bien en las primeras propuestas de Agile (y Scrum) el Product Owner estaba excluido de las retrospectivas, en recientes versiones del marco de trabajo y de la metodología se le incluye dada su perspectiva y su contribución a mejorar el rendimiento del proceso, el equipo y el producto. En soluciones intermedias lo que se acuerda con el equipo y el propio Product Owner es que este último participa en la ceremonia y cuando falta un rato para concluir se ausenta, para que el equipo tenga total libertad de hacer mención específica de aspectos relacionados directamente con este rol y/o con la persona, manteniendo la confidencialidad de quién o quiénes han emitido los comentarios y opiniones.

El rol del Product Owner es crítico, y normalmente requiere una persona con dedicación completa a un team, o como máximo dos teams.

El Scrum Master

El Scrum Master es uno de los tres roles que se pueden encontrar en Agile.

El Scrum Master es coach y líder al servicio del equipo Agile. Es el encargado de velar por que el equipo conozca y aplique el marco de trabajo (framework) o la metodología seleccionados, asegurando que están de acuerdo y siguen el proceso Agile. El Scrum Master también es el encargado de eliminar (o contribuir a que se eliminen) los impedimentos con los que se va encontrando el equipo durante la ejecución de las iteraciones. Y contribuye a establecer un entorno para que se produzcan las dinámicas necesarias que favorezcan un alto rendimiento del equipo en constante mejora.

El Scrum Master consume la mayor parte de su tiempo ayudando a los miembros del equipo a comunicarse, coordinarse, cooperar y a conseguir los objetivos que se ha fijado el team para la iteración en curso.

Veamos a continuación algunas de las responsabilidades básicas del Scrum Master:

• Muestra liderazgo. Debe liderar con el ejemplo y para ello debe tener una mentalidad Agile (o mejor, Lean-Agile) muy arraigada, y gracias a ello será capaz de ayudar al equipo a adoptar y aplicar los valores, principios y prácticas del marco Lean-Agile seleccionado por ellos o por la organización a la que pertenecen.
• Refuerza el marco de trabajo establecido en el equipo. Ese marco de trabajo puede ser tan ligero como se acuerde, pero una vez establecido es el encargado de velar por que se siga y que, por ejemplo, se celebren las ceremonias Agile acordadas, se mantenga el máximo máximo de trabajo paralelo (Work in Progress o WIP), etc.
• Facilita el progreso del team hacia los objetivos del mismo. El Scrum Master es un facilitador que contribuye al establecimiento y mejora del flujo de trabajo, la velocidad, la predictabilidad y la calidad. Para ello, en ocasiones deberá cuestionar la vigencia de las normas establecidas y ayudar al equipo a pensar si hay posibles mejoras que deban plantearse.
• Dirige los esfuerzos del equipo hacia una mejora constante. Ayuda al equipo a mejorar y toma la responsabilidades de sus acciones, y facilina las retrospectivas del equipo, utilizando y enseñándoles técnicas de resolución de problemas, si fuese necesario.
• Facilita los eventos. Debe asegurarse que las ceremonias (e.g. reuniones diarias, planificación, revisión, retrospectiva) tienen lugar, que son productivas y que mantienen el límite de tiempo acordado.
• Facilita la eliminación de impedimentos, gestionando y eliminando aquellos que están fuera del alcance del equipo y que involucran a otros team o a la organización en general. Al mismo tiempo que elimina los impedimentos, está ayudando al equipo a conseguir los objetivos que habían definido para la iteración.
• Ayuda al Product Owner a gestionar el backlog del equipo (y del producto, si fuera necesario) y a establecer un equilibrio entre las prioridades y el alcance de la iteración.
• Protege al equipo de interferencias externas. Es el paraguas que pone freno a peticiones que llegan durante la iteracion, tiene la potestad de abortar una iteración si el trabajo del equipo ha perdido sentido (por ejemplo, porque los requisitos o las prioridades han cambiado radicalmente), etc.
• Construye un equipo de alto rendimiento, ayudando a los miembros del mismo a transitar en las diferentes etapas de evolución de los equipos, ayuda a resolver internamente los conflictos interpersonales e identifica las posibles oportunidades de crecimiento. Solo escala los problemas personales a otros niveles cuando el proceso interno no ha conseguido solventarlos.

Aunque lo ideal es que un Scrum Master tenga dedicación completa a un equipo, esto no siempre tiene sentido (por volumen de trabajo o por cuestiones económicas). Habitualmente un Scrum Master da servicio a varios equipos de trabajo (idealmente no deberían ser más de tres), lo que ayuda también a la coordinación y comunicación entre equipos.

Algunas empresas incluso llegan a "sacrificar" el rol del Scrum Master como tal y en su lugar pueden tener un Agile Coach para toda la organización (por ejemplo un Agile Coach para 15 equipos en 4 ubicaciones físicas diferentes) que se encarga de velar por las ceremonias que no son diarias y el marco de trabajo y el resto de las actividades de "delegan" en los miembros del equipo, en el Product Owner o en los managers del equipo. Si bien esta situación no es la ideal, cada empresa debe tener en consideración sus circunstancias y condicionantes y a partir de ahí definir su estructura. Una vez se haya tomado la decisión, se debe conseguir que todos los integrantes de la organizaicon tengan claro el marco (setup) establecido y lo apoyen. Y, por qué no, al cabo de unos meses se puede hacer un ejercicio de Inspeccionar y Adaptar y valorar si la decisión tomada en aquel momento, con la informaicón con la que se contaba, sigue siendo válida y mantenerla o modificarla en función de las nuevas condiciones e información.