¿Son útiles los gerentes de proyecto en Scrum?

Hay tres roles definidos en Scrum: Equipo, Propietario del producto y Scrum Master. No hay un gerente de proyecto, en cambio, el trabajo de gerente de proyecto se extiende a través de los tres roles .

Por ejemplo:

• El Scrum Master: responsable del proceso. Elimina impedimentos.
• El propietario del producto: administra y prioriza la lista de trabajo a realizar para maximizar el ROI. Representa a todas las partes interesadas (clientes, partes interesadas).
• El equipo: Autogestiona su trabajo estimándolo y distribuyéndolo entre ellos. Responsable de cumplir con sus propios compromisos.

Entonces, en Scrum, ya no hay una sola persona responsable del éxito del proyecto. No hay una estructura de comando y control en su lugar. Eso parece desconcertar a mucha gente, específicamente a aquellos que no están acostumbrados a métodos ágiles y, por supuesto, a los PM.

Estoy realmente interesado en esto y cuáles son sus experiencias, ya que creo que esta es una de las cosas que pueden hacer o deshacer una implementación de Scrum.

¿Está de acuerdo con Scrum en que no se necesita un gerente de proyecto? ¿Crees que todavía se requiere ese papel? ¿Por qué?

Tal vez deberías presentar cosas como esta:

El gerente del proyecto no desapareció en Scrum . El esta todavia esta alli. ¡Hay tres de ellos ahora!

• El Scrum Master : gestiona el proceso y resuelve los impedimentos. Esa era la responsabilidad del gerente del proyecto antes.

• El propietario del producto : administra la cartera de pedidos. Esa era la responsabilidad del gerente del proyecto antes, cuando predijo todo en Microsoft Project.

• El equipo : autogestiona su producción. Quién y cómo una historia de usuario dada se convierte en un incremento de producto potencialmente liberable. Esa era la responsabilidad del gerente del proyecto cuando asignaba tareas.

Para mí, esto proviene de la falta de comprensión de lo que hace un Gerente de Proyecto y la naturaleza bastante genérica del título de PM. No soy un experto en SCRUM, pero siempre he visto que SCRUM Master reemplaza al gerente de desarrollo / líder del equipo en lugar del Gerente de proyecto.

Los gerentes de proyecto (según lo definido por metodologías como PRINCE2, que es bastante compatible con las metodologías ágiles) realmente no tienen nada que ver con el proceso de desarrollo, están cuidando el proyecto desde una perspectiva de entrega más amplia que abarca más que solo la TI construir. Hay muchas cosas que se encuentran dentro del rol de Project Manager que no están cubiertas en ningún otro lugar dentro de Scrum (administración y monitoreo del caso de negocios, administración de las partes interesadas del negocio, elementos del proyecto fuera de la construcción de TI, como reelaborar procesos de negocios, soporte, entrenamiento y así sucesivamente).

Si su PM es el tipo que cuida a los desarrolladores y no hace mucho más que eso (por ejemplo, en proyectos que son en gran parte de TI solo donde el alcance está bastante bien definido), entonces puede ser que no sea necesario en un proyecto SCRUM.

Pero antes de que alguien diga que no necesita un PM para SCRUM, me gustaría una explicación bastante clara de cómo se están cubriendo los elementos del proyecto que no son de TI y, en particular, quién administra el caso de negocios (porque los usuarios lo desean y ser algo que debe hacerse son cosas diferentes).

Puede ser que el primer ministro termine sentado más en el lado comercial del proyecto; el propietario del producto bien puede asumir más el papel del primer ministro que el Scrum Master, pero creo que es poco probable que se haya ido por completo.

Hay algunas cosas que un gerente de proyecto puede hacer que un Scrum Master o el propietario del producto podrían no ser capaces de hacer.

• Los gerentes de proyecto generalmente tienen una amplia experiencia en la ejecución de proyectos (¡sorpresa!).
• Son conscientes de los problemas comunes y pueden detectarlos y ayudarlos a evitarlos antes de que sucedan.
• Por lo general, son negociadores experimentados y pueden apoyar a otros miembros del equipo en las discusiones sobre plazos, alcance y requisitos conflictivos (muy importante si la OP es bastante nueva en el rol).
• Pueden manejar el dinero. Tienen el poder de contratar y despedir, y pueden ayudar si alguien en el equipo es incapaz de desempeñarse en su función (mediante la organización de capacitación, asesoramiento, etc.).
• Pueden ayudar a garantizar que el proyecto se ajuste efectivamente a un programa de trabajo más amplio.
• Pueden sacar cosas del camino del equipo.
• Pueden ayudar a guiar las políticas de la compañía para que sean efectivas junto con Scrum (por ejemplo, si los evaluadores aún se miden por la cantidad de errores encontrados).
• Pueden gestionar la gobernanza.
• Pueden mover los muebles.
• Su vocabulario es el de la empresa más grande, y pueden discutir el proyecto, y el enfoque Scrum, en términos de riesgo, impacto, ROI, opciones y diferenciación.
• Pueden explicarle a la junta por qué la transparencia repentina y las noticias ocasionales de fracaso, que llegan a través de un mar de informes verdes, es bueno y útil de saber.
• Un buen PM puede ayudarlo a sentirse seguro, sonar bien y verse bien.

Scrum no exige tener un PM. Pero es posible que desee tener uno de todos modos.

En uno de los proyectos en los que trabajé, cuando se convirtió en Scrum, nuestro gerente de proyecto anterior asumió alternativamente los roles de Propietario de producto y Scrum Master. Funcionó durante los 6 meses que pasé con ese equipo, aunque no fue lo ideal (para mí). Era el tipo de persona que quería mantener las cosas bajo un estricto control, pero lo hizo bastante bien (es decir, dejar que el equipo hiciera su trabajo y tomara sus decisiones cuando fuera apropiado).

El trasfondo de esto fue que la compañía estaba en una situación financiera grave, aunque nosotros (el equipo) lo supimos solo un tiempo después. Por lo tanto, había una razón para mantener todo bajo estricto control, para garantizar que solo se construyeran las cosas absolutamente necesarias y que la primera versión del producto se entregara a tiempo.

Sería justo y diría que, en mi opinión, lo que funciona para mí es que el maestro Scrum también actúe como gerente del proyecto. Ser un Scrum Master no es un trabajo a tiempo completo: una vez que el equipo está maduro, el Scrum Master ni siquiera necesita asistir a las paradas diarias.
Hay más y más vacantes que veo para un Project Manager / Scrum Master donde las empresas no quieren diferenciar estos roles, sino que la misma persona maneje ambos roles, es decir, un gerente de proyecto ágil.

Gerente de proyecto: un rol dentro de una organización o empresa tradicional.

Scrum master: un rol dentro de un equipo de desarrollo de software utilizando la metodología Scrum.

Hablar sobre el gerente de proyecto versus el maestro scrum es realmente hablar sobre manzanas y naranjas porque los roles tienen contextos diferentes. Nunca he oído hablar de una organización que tenga "Scrum master" como título oficial o grado de pago. Y los gerentes de proyecto en cualquier proyecto, Scrum o de otro tipo, a menudo se eliminan de las actividades cotidianas de desarrollo de software.

Exactamente lo que hace un gerente de proyecto y cuánto se superpone su rol con el de un maestro Scrum o propietario del proyecto depende en gran medida del tamaño y la naturaleza del proyecto, pero ciertamente hay tareas normalmente atribuidas a un gerente de proyecto que no son específicamente parte de las funciones de Scrum master o del propietario del proyecto. En un proyecto pequeño, es posible ampliar las funciones del maestro Scrum o las funciones del propietario del proyecto para incluir esas tareas (contratación, despido, compras, gestión de contratos, interacción con ejecutivos de nivel superior, etc.). En un proyecto más grande, el desarrollo de software es solo una parte de la gestión del proyecto, y es poco probable que las tareas del gerente del proyecto y las del maestro Scrum se superpongan en absoluto.

Un gerente de proyecto debe ser la interfaz del maestro Scrum para la organización. El Scrum master debe ser la interfaz del administrador del proyecto para el equipo.

Entonces, ¿son útiles los gerentes de proyecto en Scrum? No, los gerentes de proyecto son útiles fuera de Scrum. No forman parte de la metodología de desarrollo de software de Scrum, pero proporcionan los recursos que permiten que Scrum funcione.

Esta pregunta huele a Scrumbut .

Scrum es un subconjunto de lo que está contenido en un método de gestión de proyectos (Prince2 / PMP, etc.). De hecho, si observa el MP de proceso Prince2 (gestión de entrega de productos), todos los elementos de Scrum pueden estar contenidos allí.

El Scrum Master no quiere empantanarse en reuniones con vendedores, personal, legal, finanzas, proveedores, ejecutivos o BAU actividades de . Deben concentrarse en eliminar los impedimentos del equipo en el sprint actual, no negociar cuánto puede una agencia de empleo reducir las tarifas de los contratistas en el año fiscal 2011/12 o validar el acuerdo de custodia con el proveedor x.

Si su Scrum Master está haciendo lo anterior, no está ejecutando Scrum, está ejecutando Scrumbut.

Por experiencia, la mejor combinación es tener un Scrum Master para cada líder de equipo y un gerente de proyecto para coordinar a los maestros de scrum de una manera Scrum de scrums. Tener un gerente de proyecto en este rol más efectivo debido a las razones expuestas anteriormente y su profunda experiencia. A su vez, estos gerentes de proyectos se reportan en un Portfolio / Program Manager, etc. y todos en la cadena de comando son al menos Scrum Masters certificados.

Recuerde que Scrum es una herramienta para administrar la entrega de productos, en una capa de abstracción se puede usar para ejecutar proyectos, pero ya existen procesos mucho mejores para eso.

Uno de los principales problemas con el rol tradicional de gerente de proyecto es que separa la autoridad de la responsabilidad. El primer ministro tiene autoridad completa sobre la organización del proyecto: decide qué tareas se deben realizar, quién las realiza, en qué orden, etc. Pero no se hace responsable de la realización de estas tareas o de la calidad del software. eso se produce. Los miembros del equipo son los únicos responsables. Esto crea una gran sobrecarga de comunicación, ya que para devolver la autoridad y la decisión en sincronía con el trabajo operativo, los miembros del equipo tienen que informar constantemente todo lo que se hace al Primer Ministro, además del resto del equipo. También crea un sentimiento de desposesión, impotencia y pérdida de propósito con los miembros del equipo, lo cual es una gran fuente de frustración y desánimo.

Agile de alguna manera vuelve a unir estas nociones: la autoridad sobre la organización del trabajo la tiene el equipo en su conjunto (a través de la liberación, la iteración y las reuniones diarias) para que todos sientan que pueden opinar sobre el asunto, a cambio de lo cual cada uno de ellos los miembros del equipo deben asumir la responsabilidad de producir software de calidad que funcione y comprometerse firmemente con ese objetivo. Por lo tanto, teóricamente podrías deshacerte del gerente del proyecto.

Una vez que haya dicho eso, todavía hay deberes tradicionalmente asignados al primer ministro que aún deben ser atendidos, sin embargo, lunivore los describió con bastante precisión.

Como sugiere este artículo , en equipos verdaderamente multidisciplinarios, una cosa que podría hacer es descartar el rol de gerente de proyecto, redistribuir sus deberes entre los miembros del equipo y hacer que los ex PM se conviertan en miembros regulares del equipo.

Los roles de Scrum están bastante bien definidos (si parecen vagos es porque están destinados a ser aplicables en diferentes tipos de organizaciones), y dado que los equipos de Scrum son siempre (bueno, comúnmente) de aproximadamente el mismo tamaño, es decir, no muy grandes. es relativamente fácil ponerse de acuerdo sobre lo que abarcan, incluso si eso varía según la organización subyacente.

Al leer la pregunta, las respuestas y los comentarios anteriores, parece obvio que la definición del rol de gerente de proyecto es mucho más difícil de precisar. Estoy seguro de que puede encontrar una definición general agradable y compendiosa del papel de un primer ministro, pero lo que eso realmente significa en la vida real es una historia totalmente diferente.

De todos modos, como funciona en mi trabajo, los gerentes de proyecto rara vez participan en el "Scrumming" real. No se les permite ser maestros de Scrum (una regla local de conflicto de intereses de la que todos estamos muy contentos), y solo son propietarios de productos en casos excepcionales.

Entonces, donde trabajo, los gerentes de proyecto todavía están allí, haciendo más o menos lo que siempre han hecho. Lo que significa que mantienen el proyecto encaminado, actúan como un filtro contra demasiadas tendencias de paranoia y microgestión desde "arriba", resolviendo problemas que necesitan una mayor influencia de la que tenemos que resolver, y así sucesivamente.

Estoy seguro de que esto es bastante diferente en otros lugares, pero para nosotros funciona muy bien.

Editar : Tal vez debería aclarar que para nosotros, un equipo Scrum no reemplaza a un equipo de proyecto. Uno o más equipos de Scrum se ponen en marcha para realizar el trabajo real de desarrollo para (y por lo general en) un proyecto. El (los) equipo (s) de Scrum pueden (y probablemente siempre lo hagan) estar formado por los antiguos miembros del equipo, excepto el líder del proyecto :-)