¿Son útiles los gerentes de proyecto en Scrum?

17

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é?

Martin Wickman
fuente
Lo reconozco. Sin embargo, puede que ScrumMasters piense que son el nuevo PM.
Amir Rezaei
¿Quién hace el presupuesto y se sincroniza con otros proyectos?
Amir Rezaei
3
@Amir Rezae Bueno, claro que es el primer ministro. Pero no tienen que participar en el scrum. Que es exactamente lo que tenemos, un PM supervisor que se asegura de que las diversas partes del proyecto (dev y no dev) estén en camino y nadie espere los comentarios del otro. Funciona.
biziclop
¿Qué quieres decir con gerente de proyecto aquí? Estoy acostumbrado a ver a los gerentes de proyecto de un organigrama convertirse en propietarios de productos en Scrum, por lo que están muy presentes, aunque no necesariamente ejercen tanto poder como antes.
JB King
Estoy de acuerdo con @biziclop. Así es como trabajamos nosotros también. Nuestro excelente gerente de proyectos corre continuamente entre los equipos de scrum (y todas las demás personas involucradas), asegurándose de que no haya problemas serios y nos ayuda a resolverlos cuando ocurren. Pero ella no está involucrada en el "scrum" en absoluto, y así es como debería ser.
Boise

Respuestas:

15

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.


fuente
Gracias, agregué énfasis a mi pregunta para resaltar eso.
Martin Wickman
Te vi cambiar, no invalida mi respuesta. El problema, supongo, es cómo ven las cosas bien. Quieren que una sola persona administre el proceso. Explicar dónde están las responsabilidades y cómo funciona puede ayudar. Entonces, mi sugerencia es comunicar más sobre los roles y, por lo tanto, hacer que Scrum sea más claro para ellos.
¿Quién cubre elementos fuera de la compilación de TI?
Jon Hopkins
1
@ Jon: propietario del producto y Scrum Master (mucho menos que el propietario del producto). Lo que significa que el propietario del producto se parece al gerente de proyecto del que estamos hablando. Simplemente delegó cosas que no puede controlar al equipo.
@Pierre - Interesante. Mira, nunca vi que el primer ministro estuviera muy involucrado con el equipo de desarrollo, él siempre los dejaba continuar mientras administraba el negocio. Quizás solo tuve suerte.
Jon Hopkins
9

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.

Jon Hopkins
fuente
1
Diría que quizás el papel más cercano al PM clásico es el Scrum Master. El Scrum Master se asegura de que el equipo pueda trabajar de acuerdo con el plan escuchando activamente sus preocupaciones y eliminando obstáculos. Un PM como Scrum Master podría perder sus tareas anteriores (como la planificación) a medida que avanzan a un rol más consultivo -> es posible que no planifiquen realmente y estimen un sprint, pero ayudan al equipo a hacerlo y deberían estar listos para saltar si Cualquier problema surge.
Anne Schuessler
@ Anne - es un buen punto. Lo que puede encontrar es que tiene un PM en algunos proyectos, ayudando al Propietario del Producto con el caso de negocios, al Scrum Master con la planificación (particularmente las dependencias fuera del equipo) y la coordinación con elementos fuera del proyecto de TI.
Jon Hopkins
4

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.

Lunivore
fuente
1
Muchos puntos aquí, la mayoría de ellos caen en manos del PO y / o ScrumMaster por definición. Sin embargo, administrar la cartera de proyectos de la compañía es un gran punto, pero no estoy seguro de si es un deber de PM. El ROI es la preocupación de las OP.
Martin Wickman
1
La única preocupación de ROI con la que debe lidiar un gerente de proyecto. Muchas veces, un producto no tiene la intención de hacer dinero, es solo para evitar que un competidor robe participación de mercado, por lo que no habrá ningún ROI (gracias Chris Matts). A menudo tienen que trabajar con arquitectura, infraestructura, etc. para garantizar que las opciones se mantengan abiertas para el futuro. El ROI rara vez es la preocupación de la mayoría de los proyectos. Este es un muy buen ejemplo del tipo de cosas que un PM o un buen analista podrían saber, y un PO recién capacitado podría no saberlo.
Lunivore
2
¿Qué están tratando de decir aquí, que los PM son súper humanos? Eso no tiene nada de sentido. Estamos hablando de roles aquí, no de individuos. Por supuesto, un "buen analista" sabe más cosas que un "PO recién entrenado", eso es obvio. Con respecto a su respuesta: todos los puntos, excepto el punto de cartera del proyecto, son manejados por SM o PO en Scrum. ¿Y qué pasa con la conferencia ROI? Nadie dijo que el ROI era lo más importante, solo que el ROI es la preocupación de las OP (por definición).
Martin Wickman
Gracias. Esta es una excelente respuesta que me ayudará a comunicar mi punto mejor en el futuro. Pido disculpas por dar una conferencia.
Lunivore
1

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.

Péter Török
fuente
1
Interesante. Tenga en cuenta que es el OP el responsable del retorno de la inversión al asegurarse siempre de que se está construyendo lo más importante. Entonces esa parte está cubierta bastante bien.
Martin Wickman el
1

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.

Shehan
fuente
No creo estar de acuerdo con esto, creo que las aperturas para PM / SM simultáneamente se refieren a la compañía que cree en scrum que el rol de PM simplemente ha cambiado de nombre y no comprende que se haya reutilizado por completo. Eso y el conjunto de habilidades de PM sí se presta para el papel de Scrum Master (aunque más para las partes interesadas si me preguntas)
Jimmy Hoffa
1

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.

Caleb
fuente
1

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.

mosquito
fuente
2
¿Qué pasa con el comentario scrumbut? No entiendo eso.
Martin Wickman
2
@MartinWickman Lo leí como "no muy comprometido con el scrum" como en: Estamos haciendo scrum pero todavía tenemos un gerente que establece el cronograma.
Caleb
0

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.

guillaume31
fuente
0

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 :-)

Boise
fuente