Roles de Scrum - Parte I: Responsabilidades involucradas

En esta Parte I me centraré en explicar brevemente la motivación de este par de posts y presentaré la definición de los roles de Scrum. En la Parte II explicaré nuestra estrategia para implantar los roles de Scrum.

Si bien existen innumerables referencias y definiciones a los roles de Scrum poco se comenta respecto de cómo llevarlos a la práctica. Por lo visto existe una idea generalizada que basta con formación (y certificación) para conseguir gente que desempeñe eficazmente dichos roles. Además, se pasa por alto el desafío que significa migrar a las personas desde sus roles actuales. No se trata sólo de una cuestión de estrategia para convencer de las bondades del agilismo o de cómo enfrentar a quienes puedan estar en contra explícita o implícitamente de la implantación del agilismo. Conseguir que un equipo sea  self-organizing puede ser más o menos difícil, pero conseguir que un equipo sea cross-functional con miembros que no están preparados para (ni dispuestos a) abandonar sus "títulos" correspondientes a sus roles fijos, esto sí que puede ser un gran desafío.

De entre los tres roles de Scrum, el que se lleva la palma en cuanto a polémica a su alrededor es el Product Owner. Recomiendo los siguientes post para así ahorrarme el contar en detalle la problemática asociada: The Product Owner Problem, The Mythical Product Owner role.

A continuación se presenta la definición del los roles de Scrum, extraida y traducida desde la Scrum Guide (octubre de 2011).

Product Owner (PO)
Es responsable de  gestionar el Product Backlog, lo cual incluye:

• Expresar claramente los items del Product Backlog
• Ordenar los items del Product Backlog para conseguir objetivos y misión del producto
• Asegurar el valor del trabajo que realiza el Development Team
• Asegurar que el Product Backlog es visible, transparente, y claro para todos, y mostrar en qué es lo que trabajará próximamente el Scrum Team 
• Asegurar que el Development Team entiende los items contenidos en el Product Backlog

El PO debe hacer respetar sus decisiones en la organización y proteger al Development Team de las solicitudes o influencias de los stakeholders

Scrum Master (SM)

Es responsable de asegurar que Scrum es entendido y aplicado. El SM es un sirviente-líder para el Scrum Team.

Servicios del Scrum Master para el Product Owner

• Encontrar técnicas para la gestión efectiva del Product Backlog
• Ayudar a comunicar claramente la visión, objetivos e ítems del Product Backlog al Development Team
• Enseñar al Development Team a crear ítems claros y concisos en el Product Backlog
• Ayudar a comprender la planificación a largo plazo en un ambiente empírico
• Ayudar a comprender y aplicar agilidad
• Apoyar durante el sprint y las reuniones según se le requiera o sea necesario

Servicios del Scrum Master Service para el Development Team

• Entrenar en self-organization y cross-functionality
• Enseñar y dirigir hacia la creación de productos de alto valor
• Eliminar los impedimentos para su avance en el trabajo
• Apoyar durante el sprint y las reuniones cuando se le pida o sea necesario
• Entrenar para enfrentar ambientes organizacionales en los cuales Scrum aún no ha sido completamente adoptado y entendido

Servicios del Scrum Master para la Organization

• Liderar y entrenar la adopción de Scrum en la organización
• Planificar implantaciones de Scrum dentro de la organización
• Ayudar a los empleados y usuarios a comprender  e implantar Scrum y el desarrollo empírico de productos
• Provocar cambios que aumenten la productividad del Scrum Team
• Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización

Development Team

• Es self-organizing. Nadie (ni siquiera el Scrum Master) le dice cómo convertir el Product Backlog en un incremento de funcionalidad potencialmente entregable
• Es cross-functional, tiene como equipo todas las habilidades necesarias para crear un incremento del producto
• No tiene títulos más que el de Developer, independiente del trabajo que esté realizando la persona, no hay excepciones a esta regla
• Los miembros pueden tener habilidades y áreas de especialización pero ellas cuentan para el Development Team como un todo 
• No contienen sub-teams dedicados a dominios particulares como testeo o análisis de negocio
• Tiene entre 3 y 9 miembros (obviamente sin contar el PO y SM)

Si el equipo es de nueva formación, si sus miembros tienen conocimiento y experiencia en métodos ágiles o bien si tienen la habilidades y motivación para iniciarse en el agilismo, y si las condiciones de contexto cliente-producto son favorables para el agilismo, con todo ello, la opción más interesante sería implantar Scrum a fondo en el equipo. Sin embargo, dicho entorno propicio para el agilismo suele ser una excepción, con lo cual una estrategia de revolucionaria conllevaría riesgos importantes e incluso podría ser contraproducente de cara a conseguir un cambio sostenible en el proceso de desarrollo de software. Así pues, en la Parte II de este post comentaré nuestra estrategia evolutiva para implantar estos roles en un equipo que ha trabajado hasta ahora con roles y bajo un entorno de caracter más tradicional.

Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com