¿Hay correspondencia entre documentos a reportar a la PMO de proyectos en cascada y proyectos con Scrum?

La oficina de proyectos - cortesía de Tamer

Recientemente un jefe de proyecto que estuvo en uno de mis cursos de Scrum me escribió contándome que ya estaba aplicando el marco, pero que la oficina de proyectos le demanda los documentos más habituales de un proyecto en cascada, y me pidió asesoramiento sobre cuál podría ser una correspondencia de los mismos en Agile-Scrum.

No hay correspondencias, una oficina de proyectos ágil tienes las funciones de:

• Asignar y asegurar la financiación en base a la estrategia de la compañía
• Guiar, asistir y apoyar la ejecución de los proyectos
• Tomar métricas de productividad en términos de valor de negocio, satisfacción de cliente, salud en las relaciones con los partners, motivación del personal y presentación de informes que den valor a la compañía como calidad, nivel de Agilidad y time-to-market

y el cuadro de artefactos clásico sobre el que mi pidió asesoramiento tiene este aspecto:

Bien, fijémonos que el cuadro trata puntos de control que son de proceso, no de productividad sobre el valor como sería en el caso de Agilidad.

Hace más ruido un árbol que cae que todo un bosque que crece

(Oscar Andrés Rodriguez)

Hice el ejercicio por curiosidad y diversión, y busqué correspondencias aunque fuera como comparar naranjas con cebollas.

C1 Stage Gate

Project Charter with Tier determination
Correspondería a un plan de proyecto con determinación de nivel; lo más cercano a un plan de proyecto serían las actividades de la incepción ágil en la que se crea la visión, se identifica a la comunidad de comprometidos e interesados, se muestra a muy grandes rasgos la solución y se estima de forma preeliminar su tamaño.

(Draft) Business Case
Correspondería a la exploración del modelo de negocio mediante un Business Model Canvas.

High level timeline
Correspondería a la hoja de ruta de la planificación ágil, en caso correspondería a la hoja inicial que debería de ajustarse con cada en entrega a mercado o producción.

Cost estimates +/- 50
Podríamos asociarlo a una de las actividades de la incepción ágil, al ¿Cuánto cuesta? que es una estimación de costes muy a grandes números que sirve para situarnos en el orden de magnitud.

C2 Stage Gate

Completed requirements matrix/document
Correspondería a la pila de producto inicial a nivel de epics obtenida en un User Story Mapping.

Approved Business case
Correspondería al Business Model Canvas aprobado, pero ojo, en Agilidad hasta que no obtengamos feedback del mercado no habremos madurado lo suficiente... a medida que entregamos y obtenemos feedback del mercado deberemos de seguir explorando con el canvas.

Detailed Project Plan and sign-off
Correspondería a un documento que recogiera el plan del proyecto, quizá como lo propone SAFe con un lightweight epic-only business case.

Timeline
Correspondería a la planificación de release, que también está viva y se iria actualizando con cada sprint entregado.

Resource Plan
Para Scrum utilizaríamos el sprint 0 para aseguramos que todos los recursos están disponibles. Los riesgos se mitigan rápidamente en Scrum, el sprint 1 fallará si algo no está disponible ya que entregamos de forma temprana algo totalmente funcionando y potencialmente instalable en producción.

Vendor Management Plan
En Scrum se trata de trabajar de forma cotidiana y cara a cara a lo largo de todo el proyecto. Para trabajar en Scrum no debe de haber diferencias entre el personal del cliente y el del proveedor, realmente se trata de partners, y absolutamente todos los integrantes del equipo global deben de estar comprometidos con el proyecto.

Cost estimates +/- 10%
El enfoque de la Agilidad es distinto; la compañía decide desde la estrategia el presupuesto a invertir en el producto y confía en sus equipos de negocio, representados por sus Propietarios del Producto, para darles el poder de decisión para invertir en todo momento en las funcionalidades que más valor de negocio tengan. El proyecto se acaba cuando el presupuesto se acaba, pero garantizando que con el presupuesto asignando se ha invertido de la mejor forma posible y se ha construido el mejor producto posible.

Implementation Gate

Test Plan
Se acomete sprint a sprint, cada sprint debería de incluir el testing hecho al 100%, aunque podemos seguir un patrón semi-ágil para ser más clásicos y estar alineados con la oficina de proyectos. :-P

IT testing sign-off
Podríamos asociarlo a lo que ocurre en la revisión de sprint cuando repasamos todos los criterios de aceptación. En un entorno con pruebas automatizadas ocurre cuando todos los indicadores están de color verde.

Performance testing sign-off
Se deberían de hacer a los largo de los sprints o antes de subidas a producción por el equipo de testing de sistemas.

UAT sign-off
Se deberían de hacer por parte del usuario o equipo de negocio después de cada sprint entregado.

Training plan
Debería de ocurrir con cada subida a producción, recodemos que en Scrum practicamos la entrega frecuente con lo que la curva de aprendizaje es muy corta.

Project Delivery Gate checklist and sign-off
El equipo de gestión de entregas a producción deberá de tener su lista DoD de definición de hecho que deberá de cumplir antes de subir a producción.

Project Status prepared by Project Managers
No hay project managers, el avance real del proyecto se conoce con cada sprint entregado, recordemos el séptimo principio del Manifiesto Ágil: "El software que funciona es la principal medida del progreso". El progreso del sprint se conoce de forma diaria en las reuniones diarias y a través del gráfico de burndown.

Steering Committee organized by Project Mgr
El gobierno de la construcción del producto debería de garantizar que en cada momento se esté construyendo lo que más valor de negocio aporte, y eso es reponsabilidad de negocio, concretamente de los Propietarios del Producto, y en un marco escalado del equipo de Product Managment.

Project Financials prepared by Project Mgr & Project Sponsors
Es responsabilidad de los Propietarios del Producto conocer el valor de negocio y el ROI de cada historia de usuario y epic, métricas que se deben de actualizar con cada sprint.

Project Closeout lead and organized by Project Manager Participate lessons learned
El enfoque de la Agilidad es distinto; la forma ágil de conocer el éxito de un proyecto es hacer una encuesta de satisfacción al usuario final, identificar el nivel de "contento" del mismo con el producto resultante. Respecto a las lecciones aprendidas recordar que Scrum se basa en la mejora continua, una mejora que se produce poco a poco en cada sprint y a través de las retrospectivas. La cuestión es si tiene sentido buscar mejoras cuando el proyecto ya está acabado. Desde el punto de vista ágil lo ideal es que un producto/proyecto no tenga fin, ya que eso significa que está vivo y que produciendo beneficios para la compañía. Un producto que no evoluciona probablemente esté obsoleto.

Mis a agradecimientos Fidel que me ha instado a hacer este ejercicio... :-D