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.
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.
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?
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:
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?
Julio Roche es Director del área de System Development&Integration, en la práctica de Consultoría Tecnológica de Deloitte. Profesional con más de 30 años de experiencia en el mundo del desarrollo de soluciones tecnológicas, su labor se encuentra actualmente focalizada en el terreno de la movilidad y la transformación digital, donde lidera el grupo de capacidades de Movilidad dentro de Consultoria. En este grupo se encuentran las capacidades de Desarrollos de Movilidad, Contact Centre Transformation, Asistentes Digitales y Realidad Digital. Es además un referente a nivel nacional dentro del mundo de la Agilidad, habiendo participado en procesos de Transformación Ágil de grandes compañías y organizaciones.