Roles de Scrum - Parte II: Una estrategia para su implantación

Esta figura representa una posible estrategia de implantación de roles Scrum. En ella se intenta buscar el equivalente de un rol actual (con las respectivas personas que lo desempeñan) con respecto de los roles de Scrum. Aunque esta estrategia podría parecer razonable, en la práctica no suele ser factible ni coherente. Se estaría tratando de asimilar roles tradicionales con roles de Scrum. Un rol es simplemente un contenedor de ciertas responsabilidades (que conllevan unas correspondientes habilidades). Los roles tradicionales no son equivalentes a los roles Scrum en cuanto a responsabilidades y habilidades deseables para quién los desempeña.

Los roles de Scrum constituyen una excelente referencia como un ideal de roles (y correspondientemente de personas que los desempeñan), lo que querríamos tener en cualquier proyecto. Sin embargo, son de muy difícil aplicación, al menos a corto plazo para un equipo que trabaja actualmente con una metodología tradicional. A continuación se presenta un resumen de la Parte I de este post, insistiendo en el desafío que conlleva la definición de cada rol:

• Product Owner. Una persona que representa a todos los stakeholders, que lidera el desarrollo del producto, activo impulsor de una visión del producto alineada con los objetivos del negocio, que interactúa eficazmente tanto con los stakeholders como con el equipo de desarrollo, capaz de definir y organizar el trabajo pendiente, el Product Owner es parte del equipo (está in-situ o muy en contacto con el equipo).
• Scrum Master. Una persona, con profundos conocimientos y experiencia en técnicas y métodos de desarrollo de software, y en particular en agilidad, formación, entrenamiento y consultoría respecto de la metodología de trabajo, liderazgo en la implantación de mejoras de proceso, capaz de detectar y resolver oportunamente impedimentos que afecten el curso normal del proceso sin intervenir en decisiones de negocio ni técnicas.
• Development Team. Compuesto por miembros proactivos capaces de colaborar eficazmente, organizando en conjunto el trabajo que enfrentarán, que están preparados y dispuestos para realizar diferentes actividades, que aunque tengan cierta especialización sólo serán reconocidos como "Desarrollador".

Otro desafío importante es que en muchos casos las personas participan en el desarrollo y/o mantenimiento de varios productos, incluso desempeñando roles diferentes en cada producto. Los roles de Scrum se establecen para cada producto, si bien no se enfatiza que la dedicación de cada persona sea exclusiva para cada producto, se asume que esa sería la situación ideal.

Conscientes de las dificultades comentadas antes, nuestra recomendación es NO obsesionarse con conseguir al 100 % la implantación de los roles de Scrum. Esto no debería representar ningún problema a menos que se quiera ser "purista" en Scrum o se desee optar a alguna certificación asociada a Scrum :-). Nuestro interés es mejora de proceso, con lo cual utilizando como referencia los roles de Scrum intentaremos acercarnos a ellos, hasta el nivel que sea posible y deseable.

Nuestra estrategia privilegia una evolución hacia el enfoque ágil (cuando no es posible hacer una revolución). En la primera implantación e inicio del camino hacia el enfoque ágil realizamos los siguientes pasos:

PASO 1: Diagnosticar al equipo y su situación actual de roles y personas que los desempeñan (obviamente, considerando también el contexto de los productos en los cuales participa el equipo).

PASO 2: Determinar cómo se cubrirán las responsabilidades asociadas al rol Product Owner, es decir, hasta qué punto podemos conseguir el Product Owner ideal en el marco de producto (cada producto puede tener uno diferente). Para esto identificamos al menos tres responsabilidades involucradas, con las siguiente preguntas:

1. ¿Quién debería decidir qué debe implementarse en el producto (decisiones respecto de la planificación)?
2. ¿Quién debería determinar en detalle cada cambio implementado en el producto (se refiere a detallar los requisitos específicos de cada cambio)?
3. ¿Quién debería especificar/explicar los requisitos específicos a los desarrolladores?

Si, como en la mayoría de los casos, es imposible reunir estas tres responsabilidades/perfiles en una sola persona, habrá que replantearse desde un punto de vista realista cómo cubrirlas. Por ejemplo, si los clientes son varios, cada uno con sus propios intereses (posiblemente en conflicto), no quedará más remedio que consensuar los cambios del producto (o establecer un "despotismo ilustrado" :-) ), resolver conflictos y especialmente hacer una ardua labor de "venta" de los cambios realizados en el producto para que todos los clientes puedan sentirse satisfechos. En este caso, recomendamos denominar a estos participantes como Clientes. Cuando los clientes son varios es importante tener un rol que actúe de moderador e integrador de las necesidades de los clientes de cara al equipo de desarrollo. Por la habilidad y autoridad requerida para esta actividad puede resultar ser la transición más cercana para el Jefe de Proyecto, aunque en este caso preferíamos llamarlo Product Manager, y lo ideal es que efectivamente sea un representante de la parte cliente. Por otra parte, si quien debe detallar cada cambio es un Usuario Experto, lo mejor es llamarlo así. Finalmente, si la especificación del cambio en el producto la realiza un Analista de Negocio (o simplemente Analista) interactuando con usuarios expertos, sería conveniente reconocer dicho rol. Lo anterior es sólo un ejemplo de algunas situaciones que podrían presentarse y ciertas sugerencias al respecto, no pretende reflejar todas la diversidad que se podría enfrentar.

PASO 3: Determinar cuánto puede acercarse el equipo de desarrollo al rol Development Team. Lo primero que hay que evaluar es la viabilidad de prescindir de rol (y persona asociada) Jefe de Proyecto o similar, es decir, quien dirige al equipo, organizando y supervisando el trabajo, es decir, si el equipo está preparado para ser self-organizing, o al menos en alguna medida. Además, si se quiere y puede llevar el concepto de self-organizing a fondo, habría que resolver qué reubicación se le daría al actual Jefe de Proyecto o similar. En segundo término habría que evaluar la preparación y disposición del equipo respecto de abandonar cargos específicos o agrupaciones internas por funcionalidad (analistas, programadores, testers, etc.) con la idea que cada miembro del equipo pueda llegar a realizar cualquier actividad, aunque indudablemente pueda estár más especializado en alguna de ellas. Para esto hay que conocer con detalle qué actividades se están desarrollando actualmente y decidir si todas se abordarían con el rol genérico de Desarrollador o se mantendrían algunas con roles (y responsables) específicos y fijos. Por otra parte, con el propósito que el equipo sea cross-functional habría que intentar que todas las habilidades necesarias para conseguir una versión del producto estén disponibles y cubiertas por los desarrolladores. Si bien podrían existir ciertos miembros cosultores que no estén a tiempo completo en el equipo, los desarrolladores no deberían depender de personas no incluidas en el equipo de desarrollo para poder dar por terminado el trabajo de una versión del producto. El outsourcing de ciertas actividades y/o los equipos funcionales (por ejemplo, el área o equipo de QA) son obstáculos importantes para el concepto de cross-functional, sin embargo, si el planteamiento no es "todo o nada" es posible conseguir en parte las ventajas de dicho concepto cuando no interesa prescindir del outsourcing o de los equipos funcionales. Además, por ejemplo en el caso de outsourcing, si se consigue que el personal del proveedor esté co-localizado con el equipo de desarrollo ya no existen mayores inconvenientes al respecto. Sucedería lo mismo si, por ejemplo, se consigue que personal de QA pueda tener cierta dedicación exclusiva y co-localización con el equipo de desarrollo, aunque sea por temporadas.

Consideraciones adicionales:

• Si no se tiene una implantación exacta de un rol, tal como lo define Scrum, NO utilizamos el nombre de rol dado en Scrum y usamos un nombre alternativo, nuevo o coincidente con uno ya empleado en el equipo. 
• Scrum Master es un rol que exige experiencia. La primera implantación se recomienda que sea liderada por un consultor externo que desempeñe el rol de Scrum Master. Éste debe ser un especialista en el enfoque ágil, que trabaje en conjunto con la persona del equipo seleccionada para formarse como Scrum Master. La idea es que después de la primera implantación quede formado un Scrum Master para el equipo, el cual pueda continuar la mejora del proceso sin la necesidad del consultor externo. El Scrum Master (externo o interno) tiene mucho más protagonismo al inicio de la implantación de Scrum en un equipo. Con el tiempo el Scrum Master es menos protagonista pero mantiene su presencia en cuanto a la promoción de la mejora continua del proceso, aunque probablemente sea suficiente que un Scrum Master tenga una dedicación a tiempo partial para un equipo.

El radicalismo en cuanto a roles planteado por la Scrum Guide, aunque ideal y conveniente, no es posible llevarlo a la práctica en la mayoría de los casos, o al menos no de inmediato para un equipo que ha trabajado con un enfoque tradicional, y para productos en los cuales no es posible tener un Product Owner puristamente. Mike Cohn aporta un toque de pragmatismo al respecto en su libro "Succeding with Agile. Software Development using Scrum".

Es indudable que cada producto-cliente-equipo tiene sus propias necesidades en cuanto a configuración metodológica, las recetas generales son sólo eso, debe siempre hacerse una adaptación al contexto para sacar el máximo de beneficio y luego ir ajustándola según el desempeño que se observe y/o se desee alcanzar. En TUNE-UP Process, y promoviendo una estrategia evolutiva hacia el enfoque ágil, se proporcionan mecanismos específicos para facilitar la configuración metodológica y luego facilitar su modificación hacia estrategias más puristas.



Patricio Letelier

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