Scrum y el Project Manager. ¿Qué hacemos con él?

Este es un tema recurrente cada vez que realizamos una implantación del modelo Scrum en un cliente: ¿qué hacemos con nuestros Jefes de Proyecto? Hay varias tendencias que surgen de manera casi automática; “Convirtámoslos en Scrum Masters”, donde subyace un interés malévolo por cubrir esa posición con alguien que pueda seguir controlando al equipo como se hacía habitualmente; “Integrémoslo en el Dev Team y que siga controlando al equipo y reportando el avance del proyecto”, donde nada subyace, simplemente se trata de no quitar los galones a este perfil, tan crítico en la metodología tradicional, pero que impedirá que el equipo de desarrollo y por ende el Equipo Scrum se desarrolle correctamente.

Como bien dice la guía Scrum, "El equipo de Scrum está formado por un Product Owner, el Equipo de Desarrollo y un Scrum Master. Los equipos Scrum son auto-organizados y multifuncionales – Guía Scrum 2017 ”. 

Muchos consideran que esto es una prueba de que la función del Project Manager ha quedado obsoleta. Siguiendo está lógica los roles de Gestión, Ventas, Relaciones con Cliente, Operaciones Comerciales, Operaciones de TI, el propio usuario y el cliente, estarían obsoletos al no aparecer explícitamente en la Guía Scrum.

Scrum engloba a todos ellos como partes interesadas o incluso como miembros del equipo de desarrollo. 

Esto, lejos de ser un olvido, tiene toda la intención dado que Scrum, no nos olvidemos, es un marco de trabajo. Este marco como bien sabéis, consta de 3 roles, 3 artefactos y 5 eventos, es deliberadamente ligero, de modo que el marco de trabajo puede utilizarse en muchos entornos diferentes. En algunos de estos entornos nos encontraremos con funciones que podamos asignar o sean responsabilidad de un Project Manager. En muchos otros entornos no. Por lo tanto, Scrum utiliza el término "parte interesada" en su lugar.

Project Manager vs. Equipo Scrum

En Scrum muchas de las tareas tradicionales asignadas a los Project Manager están de manera velada incluidas en las responsabilidades de los equipos Scrum:

Los Equipos Scrum (y los Equipos de Desarrollo) están auto-organizando su trabajo para crear incrementos potencialmente liberables.

El Product Owner gestiona el Product Backlog que ordenará lo que se está construyendo.

• Los equipos de Scrum determinan la meta de Sprint y determinan qué debe ser recogido de Backlog para lograrlo.
• En la revisión "el Product Owner discute el Product Backlog tal y como está. Él o ella proyecta el objetivo probable y las fechas de entrega basándose en el progreso hasta la fecha (si es necesario);" - Guía Scrum 2017
• El equipo de Scrum gestiona los riesgos utilizando Scrum. Hacen que sus artefactos sean lo más transparentes posible y se encargan de planificar por Sprint.

Lo que también es importante tener en cuenta, es que los equipos Scrum trabajan en los productos lo que hace que el nombre de "Project Manager" sea difícil de usar. Al final se puede argumentar que un nombre diferente sería más apropiado.

A menudo también se considera a los jefes de proyecto como personas que empujan el trabajo a los equipos, mientras que en Scrum los equipos sacan el trabajo del Product Backlog. Por lo tanto, la forma en que el Project Manager se relaciona con el equipo evidentemente ya no puede ser la misma que antes.

Por todo esto, generalmente acabamos formulándonos la siguiente pregunta:

¿Realmente necesitamos Project Managers cuando utiliza Scrum?

La necesidad de un Project Manager

En muchas organizaciones, el papel de Project Manager desapareció al implantar Scrum, pero ciertamente hay muchas otras organizaciones que aún lo mantienen. A menudo su trabajo sigue siendo de mucho valor, aunque su encaje organizativo haya sido complejo de organizar. 

Aquí os mostramos algunas situaciones en las que se podría ser interesante el requerir el papel de Project Manager:

• El equipo Scrum depende de personas o equipos que están fuera de su control. Es cierto que la Guía Scrum dice que los "Equipos de Desarrollo son multifuncionales, con todas las habilidades como equipo necesarias para crear un incremento de producto;". Muchas organizaciones están trabajando en este sentido, pero a menudo no es fácil de establecer.
• Algunas partes de la organización quieren una forma diferente de mantenerse al día que a través de los eventos Scrum. A modo de ejemplo: organizaciones que todavía tienen comités directivos. Yo diría que la Revisión Sprint puede reemplazar esto perfectamente, mejorando la transparencia, pero esto simplemente no está establecido en todas partes.
• Los equipos de Scrum sólo cubren una pieza del rompecabezas del producto, a menudo sólo el desarrollo de software. Todas las demás piezas que componen un producto completo (como ventas y operaciones) no están dentro del mundo Scrum. Un Gerente de Proyecto típicamente maneja la parte fuera de Scrum. En mi opinión, sería mejor presentar a los otros equipos también a Scrum para que todos puedan beneficiarse de él. También diría que esto es parte de lo que un Propietario de Producto puede hacer.
• Scrum es perjudicial para una organización. Las prácticas y los roles que solían ser clave pueden terminar por dejar de serlo. Reconocer esto puede tomar tiempo.

Concluyendo

En muchas organizaciones aún se trabaja con Project Managers que se comunican con los equipos de Scrum, bien porque estemos comenzando la implantación de Scrum o bien porque aún no hayamos conseguido realizar la transición al mundo agile. Seamos consicientes que este es un hecho al que nos tenemos que enfrentar.

La mayor parte de las responsabilidades de un gestor de proyectos tradicional están dentro del equipo de Scrum, sin embargo, la mayoría de las organizaciones todavía sienten la necesidad de tener a alguien que conecte los puntos entre el mundo Scrum y el mundo sin Scrum (a menudo TI o desarrollo de software frente al resto de la organización). 

Estos Project Managers deben respetar que el Product Owner, Scrum Master y el Equipo de Desarrollo tienen responsabilidades que solían recaer en el Gerente de Proyecto antes de la llegada de Scrum y que hay que compatibilizar buscando una vía de transición de las mismas.

Larga a vida al Project Manager, ¿o no?