Un colega y yo tuvimos una discusión hace unos días sobre dónde se colocaría un PM en un proyecto de Prince2 cuando la entrega del producto se realiza mediante Scrum.
Me pregunto cuáles son tus pensamientos:
La respuesta puede depender de la naturaleza del proyecto.
Si el proyecto se trata únicamente de la entrega y la implementación técnica de un producto de software, entonces tal vez no haya lugar para un PM en el rol que sería reconocido dentro de Prince 2, aunque eso es discutible, ya que sospecho que existen pocos proyectos. para entregar solo software.
Si, como puede ser más probable, el proyecto abarca cambios comerciales sustanciales, adquisición e implementación de infraestructura de hardware y software, desarrollo y entrega de capacitación para usuarios finales, gestión financiera, informes de proyectos y programas, gestión de riesgos y realización de beneficios, junto con la desarrollo de software, entonces creo que el PM tiene un papel importante.
El PM no debe ser el Scrum Master, en mi opinión, ni debe ser el propietario del producto. El PM en Prince 2 puede estar bastante divorciado de la entrega técnica. El rol debe centrarse en garantizar que los equipos de entrega sepan lo que se espera que entreguen, y luego mantenerse al tanto de los riesgos, la planificación y realización de beneficios, la calidad y el progreso. En tal rol, el PM puede estar administrando varios proyectos pequeños simultáneamente, o un proyecto grande que necesita un alto nivel de coordinación y presentación de informes.
Su pregunta se refiere a la comunicación hacia y desde el PM: esto probablemente debería ser con el Propietario del producto, quien en términos de Prince 2 probablemente podría considerarse un Gerente de equipo. También pregunta sobre el nivel de participación que el PM debería tener en la entrega diaria: creo que esto debería ser muy limitado.
La respuesta es: depende mucho de la situación.
Si puede aplicar Scrum al pie de la letra y tiene un cliente dispuesto a asumir su rol y un equipo tiene algo de experiencia con Scrum , puede haber un pequeño lugar para PM tal como se entiende en Prince2. Considero que hay un Product Owner del lado del cliente que participa en las sesiones de planificación y demostración de la aplicación, es una persona de referencia cuando el equipo tiene dudas sobre las historias, etc. También considero que el equipo maneja el trabajo bastante bien. En dicho entorno, el rol de PM se divide entre todos los miembros del equipo y el cliente, por lo que los propios PM no se adaptan bien a la imagen. Sin embargo, es una situación bastante rara.
Si el cliente no quiere cambiar su forma de trabajar y espera que el proyecto se entregue "a la antigua usanza"Todavía puede organizar la producción de acuerdo con Scrum, pero tendrá brechas en todas partes cuando espere la participación directa del cliente, la más grande es la función del propietario del producto. En tal situación, PM es el mejor candidato para jugar como una especie de puente y/o traductor de ambos mundos: ágil del lado del proveedor y formalizado del lado del cliente. Cada vez que el equipo necesita una entrada de PO, le preguntan al PM quién está imitando este rol y obtienen todas las respuestas del cliente como lo haría normalmente el PM. En este caso, probablemente también haya una expectativa por parte del cliente de cumplir con un conjunto específico de requisitos formales (como documentación, planes de proyecto, etc.), que nuevamente es una tarea común dirigida a los PM. Nota:
El último caso es cuando los equipos tienen problemas con Scrum. Entonces podría valer la pena considerar tener PM como Scrum Master. Sin embargo, no es una idea segura. Consideraría cuidadosamente si PM cree en el éxito del método, lo sabe y es capaz de ayudar al equipo de la manera en que se supone que debe funcionar SM, lo que significa no decirle al equipo cómo deben trabajar exactamente, sino más bien facilitar las discusiones del equipo para poder recordarles los principios. Debido a las características específicas del rol de PM, podría ser una buena idea, ya que el PM rara vez tiene un poder directo sobre el equipo. Sin embargo, también me parece arriesgado, ya que a menudo es tentador para los ex PM simplemente decirles a las personas qué hacer y no solo aconsejarles. En este caso, la comunicación sería más o menos igual que en un escenario típico con SM.
No es difícil integrar PRINCE2 y Scrum. El proyecto PRINCE2 procede según el manual y durante la actividad Aprobar un paquete de trabajo de Control de una etapa, PRINCE2 PM actúa como Propietario del producto (porque representa los requisitos del cliente). El Team Manager que acepta (probablemente el líder del equipo de desarrollo) implementa Scrum en el proceso de gestión de la entrega del producto y trata el paquete de trabajo como la cartera de pedidos del producto. Este Product Backlog se divide en tantos Sprints como sea necesario y siempre que todo el proceso esté completo para el momento en que el Paquete de trabajo debía completarse, el PM casi no tiene interés en las actividades que se llevan a cabo y solo espera recibir Informes de puntos de control. a intervalos acordados. El PM puede o no decidir asistir al Scrum diario.
La única otra interacción que llevará a cabo el PM es recibir Informes de problemas del Scrum Master y mantenerlo informado sobre el asunto y el PM también pasará los cambios al líder del Equipo de desarrollo. Cómo se analizan y se toman medidas sobre estos problemas y cómo se aprueban los cambios no le concierne al equipo Scrum, el PM maneja estas actividades utilizando el enfoque PRINCE2.
Como puede ver, no hay superposición ni modificación de ninguna de las dos metodologías. Tanto las metodologías PRINCE2 como Scrum están intactas y ni el PM ni el equipo Scrum necesitan cargar con más responsabilidad de la que habrían tenido antes de combinar los enfoques.
segador_unique