Roles y responsabilidades Scrum: un paso hacia la transparencia y el compromiso

Puedes leer en este enlace el primer artículo de esta serie: Agilidad, complejidad y método empírico

¿Cómo se reparten las responsabilidades dentro de un equipo Scrum? ¿Cómo el trabajo de unos ayuda a que sea posible el trabajo de los otros?

La transparencia y la claridad son siempre importantes, pero que conozcamos qué hay que hacer, quién es el responsable de hacerlo y/o garantizar que ocurra ayuda a simplificar las cosas, a que entendamos cómo colaborar y favorece el compromiso.

Con el fin de garantizar que avanzamos y tomamos decisiones basadas en aprendizaje validado, en hechos y no en suposiciones, y que minimizamos el desperdicio, Scrum es necesariamente iterativo. Veíamos como Scrum era un marco de trabajo diseñado para construir soluciones adaptables a problemas complejos. Para garantizar el éxito, Scrum define una serie de reglas que guiarán las relaciones e interacciones de las personas del equipo. Los tres pilares del método empírico (transparencia, inspección y adaptación), los cinco valores (compromiso, foco, apertura, respeto y coraje) y las partes necesarias (eventos, artefactos y roles).

Cuando definimos los roles y las responsabilidades asociadas a cada persona, estamos indicando en qué debemos poner el foco cada uno de los miembros del equipo para conseguir los objetivos comunes, y estamos aportando transparencia y mejorando la eficiencia. No solo sabremos en qué debemos centrarnos a nivel individual, también cómo y cuándo prestar o pedir ayuda, cuándo ser o no proactivo. Es decir, facilitamos la colaboración y aumentamos la probabilidad de éxito, ya que tener un buen resultado no depende de las acciones individuales de cada persona que participa en un producto o en un proyecto, sino de cómo de bien o mal colaboran entre ellas.

Teniendo clara nuestra misión, nuestras responsabilidades y las expectativas que se tiene sobre nosotros es más fácil garantizar el compromiso. Scrum define los roles y las responsabilidades que son necesarios para diseñar equipos que puedan liberar en cada sprint el incremento de valor deseado.

Diseño y configuración de los equipos

Scrum pone a nuestra disposición herramientas clave para que los equipos estén enfocados y evolucionen hacia una cohesión cada vez mayor. Pero para garantizar el éxito, es necesario que el equipo cumpla algunas premisas más:

• Que tenga todas las habilidades para crear cada sprint un incremento valioso y útil. Es decir, todo el conocimiento y todas las capacidades están dentro y/o disponibles para el equipo.
• Autogestionado, deciden quién hace qué, cómo y cuándo. Es decir, no hay jerarquías ni sub-equipos que limiten esta capacidad de flexibilidad y agilidad para organizarse y tomar decisiones.
• Se busca optimizar la comunicación y la productividad. Para ello se elige un tamaño de equipo que aporte la capacidad suficiente para generar valor en cada sprint y permanecer ágiles. Se sabe que la comunicación y la productividad son mejores cuando los equipos no superan los 10 miembros. Cuando el producto es muy grande, y para tener un time to market adecuado, necesitamos más personas. La recomendación es hacer equipos más pequeños que cumplan las características anteriores, y todos ellos compartiendo Product Backlog y Product Owner.

Otra consideración es que el equipo Scrum debe ser responsable de todas las actividades relacionadas con el producto, desde la investigación y la experimentación al desarrollo, la verificación, la operación y el mantenimiento. Todo el equipo Scrum es responsable de crear un incremento valioso y útil en cada sprint.

El diseño y configuración de equipos es un tema complejo para las organizaciones. Es muy frecuente encontrarnos con estructuras organizativas que dificultan la comunicación, que generan silos, que dan poca flexibilidad o en la que no se aprovecha la capacidad que podríamos aportar cada uno de nosotros.

Scrum define tres roles, con tres responsabilidades principales: Product Owner, Desarrolladores y Scrum Master.

Funciones del Product Owner

Conocer los objetivos del negocio, las necesidades de los usuarios, el problema a resolver y el punto del que partimos es la mejor forma de empezar un proyecto, y en Scrum existe un rol específico, el de Product Owner, muy centrado en esta área.

Un producto puede ser un servicio, un producto físico, algo más abstracto, pero siempre es un vehículo para entregar valor, y el Product Owner es la persona responsable de maximizarlo. El valor se obtiene como resultado del trabajo del equipo en cada sprint. El Product Owner debe conocer perfectamente el propósito del producto, las necesidades que resuelve, el público objetivo, el valor diferencial, el valor que se espera obtener a partir de él, y debe ser capaz de transmitirlo al resto de personas implicadas.

Con respecto a un producto dentro de una organización habrá distintos stakeholders, distintas personas interesadas que tengan sus propios objetivos, sus intereses particulares. Por ejemplo, podemos tener un departamento de marketing que, para conseguir implementar una estrategia de captación de usuarios, necesite que se haga un desarrollo concreto; pero también podemos tener un departamento de ingeniería que para mejorar el rendimiento necesite que se haga otro desarrollo concreto. La capacidad del equipo es limitada.

El Product Owner debe ser capaz de recoger y priorizar en base a valor las distintas necesidades. Debe estar empoderado para tomar decisiones, y la organización debe respetar sus decisiones.

El trabajo pendiente del producto, es decir, las funcionalidades que creemos que nos van a ayudar a conseguir la misión del producto estarán recogidas y priorizadas en el Product Backlog. El Product Owner es el responsable del Product Backlog, es su responsabilidad incluir y priorizar cualquier nuevo elemento que sea necesario. También es responsable de que el equipo conozca y entienda cada elemento de trabajo pendiente, y podrá delegar alguna de estas tareas, pero es el responsable último de ellas.

El papel de los desarrolladores en Scrum

Los desarrolladores son las personas del equipo que se comprometen a crear cualquier aspecto de un incremento útil, de un incremento funcional en cada sprint.

Para Scrum el equipo de desarrollo incluye personas de las especialidades que se necesite; por ejemplo, un Diseñador, un experto en UX o un QA pueden formar parte del equipo de desarrollo.

Para poder comprometerse y tener éxito en su misión de construir un incremento funcional correspondiente al objetivo fijado en la planificación del sprint, el equipo de desarrollo deberá conocer y comprender el objetivo, y diseñar un plan para alcanzarlo. El plan comprende no sólo cuál va a ser la solución técnica, sino qué tareas tenemos que llevar a cabo para implementar dicha solución y cómo nos vamos a organizar para conseguirlo. Además, tiene que ser una solución de calidad, que esté terminada y preparada para poner en manos de los usuarios finales.

¿Cuándo se considera que una tarea está lista? Para evitar desajustes a la hora de comprender el alcance de las tareas, se utiliza un acuerdo llamado Definition of Done. El plan del equipo debe garantizar la calidad, debe cumplir el Definition of Done. El plan se recoge en el Sprint Backlog.

Después, durante la ejecución del sprint, día a día el equipo de desarrollo es responsable de inspeccionar y adaptar su plan hacia el objetivo del sprint.

La responsabilidad de ser Scrum Master

El Scrum Master es el responsable de establecer y de implantar Scrum tal como lo define la guía. Para ello trabaja al servicio de: la organización, el Product Owner y los desarrolladores.

Lo primero es centrarse en que todos comprendan la teoría y la práctica de Scrum. Para poder cumplir su misión, el Scrum Master debe o puede:

• Capacitar a la organización, ayudarla a planificar la implantación de Scrum, y a familiarizarse con el uso del enfoque empírico para abordar problemas complejos.
• Ayudará al Product Owner: a encontrar técnicas para una definición eficaz de objetivos; a comunicar de manera clara y concisa los elementos de trabajo pendientes; a planificar el producto con un enfoque empírico; y facilitando la colaboración entre las partes interesadas.
• Y ayudará al equipo de desarrollo acompañándolo en su camino para capacitarse y llegar a ser un equipo autogestionado y multifuncional. Facilitará que se mantengan enfocados en la generación del incremento de valor que cumpla el DoD. Para ello, promoverá la eliminación de impedimentos, de dependencias y bloqueos. Es importante entender que el Scrum Master no es el encargado de eliminar estos impedimentos, sino de capacitar al equipo y a la organización para identificar y anticipar las cosas necesarias, y para saber cómo gestionarlas. Y también asegura que todos los eventos se ejecutan en tiempo y cumplen su cometido.

Ingredientes clave

Todos los roles y todas las funciones son necesarias e importantes para conseguir el producto deseado y necesario.

• El Product Owner será persona que proveerá, inicialmente, el foco para el equipo a través del objetivo del producto; también determinará la estrategia a través de la priorización que realiza sobre los distintos elementos de trabajo pendientes, sobre las distintas funcionalidades; y también proveerá transparencia desde el principio comunicando de forma clara y concisa todos estos elementos de trabajo pendientes a través del product backlog y de su participación en los distintos eventos.
• El equipo de desarrollo es el encargado de convertir en realidad el producto, con su conocimiento, sus capacidades, su flexibilidad para adaptarse y aportar soluciones de manera eficiente. Son quienes finalmente hacen que los usuarios tengan una solución entre sus manos.
• El Scrum Master ayudará a seguir las reglas del juego, facilitará la colaboración entre todas las partes, buscará un alineamiento pleno del equipo. También acompañará a todos en la consecución de sus misiones, y en su desarrollo y madurez como equipo.

Y de esta forma, entre todos consiguen, sprint a sprint, tener un software funcionando que poder poner de manera temprana en manos de los usuarios para recibir feedback y aprender, al mismo tiempo que se desarrollan y maduran como equipo a lo largo del proceso.