Por qué es tan difícil educar a un gestor de proyectos Waterfall para asumir una función en un equipo de Scrum?

(Playa de Cabanas, Portugal) Mucho se ha escrito en este blog sobre los beneficios de la metodología Agile. La verdad es que, en el momento en que una organización decide iniciar una Transformación Agile, particularmente, adoptar la práctica del Scrum, la reeducación de los recursos humanos puede ser un desafío aterrorizante. La experiencia necesaria para una función de Scrum Master o Product Owner, es muy diferente de lo que normalmente se encuentra en un recurso experimentado actuando como gestor de proyectos Waterfall.

La experiencia passada de un gestor de proyecto Waterfall

En Waterfall, el principal objetivo de un gestor de proyecto es entregar el proyecto dentro del tiempo, alcance de los objetivos iniciales y calidad previamente acordados. El proyecto Waterfall sigue un proceso secuencial en V, partiendo de la fase de requisitos, y siguiendo para desarrollo, pruebas, entrenamiento, soporte y mantenimiento.

El gestor de proyectos tiene un papel de facilitador, organizando todos los recursos necesarios, condiciones y materiales, respetando el roadmap acordado, informando a los stakeholders y patrocinadores del proyecto, atenuando los riesgos, si es necesario, y desarrollando planes de contingencia. Él se siente más comprometido con el “hacer acontecer” que con “lo que se entrega”.

He escuchado en mi carrera gestores de proyecto Waterfall decir con algún orgullo: “Hice un proyecto SAP sin haber abierto una aplicación SAP”. Para mí esto es completamente inconcebible …

Un gestor de proyecto de Waterfall tiene una perspectiva de compromiso temporal: está de paso hasta el lanzamiento del proyecto, después parte para otro proyecto. Este es el enfoque del proyecto y no el enfoque del producto. En el enfoque del producto, tenemos un compromiso a largo plazo y un compromiso con el valor que se entregará permanentemente al cliente.

El gestor de proyectos Waterfall tiene su foco en satisfacer a los patrocinios y los stakeholders: entrega en el tiempo adecuado, alcance, presupuesto y calidad. No observamos aquí un papel importante para usuarios y clientes. Los usuarios y clientes se toman en cuenta en 2 momentos diferentes:

  • 1er momento: durante la fase de requisitos.
  • 2º momento: durante pruebas, validación y aceptación del proyecto, entrenamiento y soporte.

En este segundo momento, los usuarios o clientes están expuestos a una versión completa del producto, a un conjunto de funcionalidades. El feedback recolectada es acumulada y no tan detallada funcionalidad por funcionalidad, como en el fondo se hace cada Sprint Review.

Tenga en cuenta, en Waterdall, la presencia del gestor de proyecto en estos 2 momentos de interacción no es obligatoria. Estas tareas generalmente son delegadas a especialistas, no siendo obligatoriamente contribución directa por parte del gestor de proyecto.

Otras tareas normalmente no consideradas por el gestor de proyectos Waterfall: retrospectiva y mejora continua. El gestor del proyecto Waterfall normalmente no organiza reuniones retrospectivas con el equipo de desarrollo, no siente como su responsabilidad la satisfacción, la gestión de la capacidad y la velocidad del equipo. Tal como tampoco siente como su responsabilidad tener una actitud permanente de buscar la mejora en todo lo que está relacionado con el producto, equipo y procesos.

 Cuál es la razón por la cual la experiencia del gestor de proyectos Waterfall no trae tanto valor para la práctica Agile

Los tipos de competencias y experiencias que desarrolla un gestor de proyecto Waterfall son normalmente las siguientes:

  • Identifica recursos especializados necesarios para realizar tareas de proyecto;
  • Guarda y actualiza presupuesto y Roadmap;
  • Regularmente requiere actualizaciones sobre estado, riesgos y dependencias del equipo de implementación y los resume en reuniones de dirección para los managers y los stakeholders;
  • Organiza el escalonamiento de asuntos si es necesario;
  • Las competencias de comunicación y negociación son fundamentales: organiza reuniones y modera discusiones en diferentes niveles jerárquicos: a nivel inferior con especialistas, de nivel superior para actualización ejecutiva y escalonamiento de problemas.

Estas competencias son apreciadas en cualquier proyecto, pero en Agile los equipos y las funciones están organizadas de una forma diferente y parte de las tareas descritas arriba se distribuyen por diferentes funciones.

Un equipo Agile es autoorganizado, cada miembro del equipo conoce su área de especialización y asume responsabilidad de implementación voluntariamente sobre las historias o tareas que cree ser competente para comprometerse con la entrega. Con el tiempo, el equipo generalmente selecciona “naturalmente” quién es el experto en lo que: quién es el test manager, el arquitecto, el programador backend, etc.

La asignación de historias es hecha por Scrum Master o por cada miembro del equipo, reconociendo sus áreas de especialización individuales, asumiendo espontáneamente su propia responsabilidad.

La escalada, la mitigación de riesgos y el desbloqueo de impedimentos es una tarea Scrum Master. Pero es también tarea del Scrum Master, buscar la mejora continua de desempeño, motivación y satisfacción del equipo, lo que nunca observamos en un gestor de proyecto Waterfall.

El Product Owner trae la visión del producto, funcionalidades, es la voz del cliente. Tráz esencialmente requisitos, compromiso para construir el mejor producto, consolidando la estrategia en valor para el cliente.

Como pueden ver, este es un cambio radical de mindset entre los actores de la metodología Waterfall y Agile pero, esencialmente, se trata de un gran desafío para un gestor del proyecto de la Waterfall especializarse técnicamente y comprometerse con el producto y los usuarios más que con los apiladores.




Dejar una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.