¿Cómo cambia el trabajo de un gerente de proyecto cuando se hace la transición de cascada a Agile?

Hice la transición y también ayudé a otros a hacer la transición (con diversos grados de éxito :-)

Cambios de alto nivel:

1. Estarás más en un rol de servidor que en un "rol de capitán del barco" (pero aún tienes responsabilidad y responsabilidad...)
2. Rápidamente encontrará que su tiempo administrando cosas (por ejemplo, el seguimiento de las hojas de tiempo) se reduce
3. Su comunicación entre departamentos y equipos (cara a cara) aumentará drásticamente
4. Se centrará menos en el estado y más en los problemas y riesgos
5. Pasará gran parte de su tiempo hablando con clientes o gerentes/propietarios de productos en busca de participación, aclaración e información.
6. Su nivel de comodidad disminuirá hasta que usted y su equipo realmente confíen el uno en el otro.

Muchos de estos son discutibles. Conozco a muchas personas que no dejarán de lado la administración del "estilo antiguo" de un proyecto, aunque el equipo no encuentre valor en él y los métodos ágiles no lo admitan fácilmente (Earned Value es un gran ejemplo de esto). ) Además, hay PM ágiles que no son tan prácticos con el equipo, por lo que la resolución de problemas y la "eliminación de obstáculos" se trasladan a otras funciones/personas.

Los detalles de las actividades del día a día son difíciles de generalizar, pero... (muchos de los siguientes asumen que Scrum es su método Agile)

1. Asistirás a una reunión diaria de pie con el equipo.
2. Estarás sudando sobre la acumulación de productos para asegurarte de que esté actualizado
3. Pasará algún tiempo mirando (y manteniendo) los gráficos de quemado y de quemado
4. Revisará notas retrospectivas y propondrá sugerencias para que el equipo mejore su proceso.
5. Organizará la revisión del cliente del producto que se está produciendo.
6. Con suerte, se sentará con el equipo y escuchará sus discusiones y usará su experiencia para ayudar con problemas y obstáculos personales e interpersonales.

¡mmmv!

En primer lugar, es posible que desee echar un vistazo a la pregunta muy relacionada sobre el papel de PM en proyectos ágiles .

Luego, la transición específica depende en gran medida del tipo de proyectos que ejecute. Si trabaja en una solución sobre la que tiene control total, como proyectos internos sin un cliente que pague fuera de la organización, puede terminar en un punto en el que no haya un rol formal de PM en el equipo del proyecto. Este sería un ejemplo clásico de implementación de Scrum al pie de la letra. A menudo, en tales situaciones, PM se convierte en Scrum Master, pero es una solución complicada, ya que Scrum Master es más un entrenador que un líder de proyecto. Otra idea, y mejor, es optar por el rol de Product Owner, aunque se trata más de tratar con el producto que con el proyecto. De cualquier manera, Scrum distribuye parte de los deberes típicos de un PM en el equipo.

El otro tipo de proyectos es cuando realmente tienes algún tipo de cliente externo y este cliente probablemente se acostumbró a ejecutar proyectos de una manera más formal. Después de todo, si la transición es algo nuevo para usted, probablemente también sea algo nuevo para sus clientes. En este caso, el papel más importante del PM es traducir la forma en que trabaja el equipo al cliente (también al revés) y llenar los vacíos que puedan existir. Estas brechas generalmente se relacionan más con el lado formal de la gestión de proyectos, ya que los equipos ágiles generalmente intentan minimizarlo, aunque los clientes a veces esperan muchos artefactos formales. Puede leer más sobre este enfoque en la pregunta sobre la fusión de diferentes enfoques de PM dentro de la misma organización .