Esta nota surge de la práctica proyectual y de ver cómo PMBOK y Agile se están relacionando cada vez más, lo que permite hablar de la Gestión Ágil del Proyecto, que no es más que usar Agile en el marco de la gestión de proyectos sin que nadie predomine.
Más allá de que suene guapo hablar de Gestión Ágil de Proyectos, la idea es que esta expresión permite unir dos ideas.
La gestión de proyectos puedo resumirla en que hace todo lo posible para reducir incertezas y detectar las zonas de incerteza que deberán soportarse en un proyecto, pero siempre requerirá ayudas para moverse en la incertidumbre.
Agile aporta algo que puedo sincretizar como un comportamiento y una actitud ante la incerteza continua lo cual es super útil a la gestión de proyectos.
Así Gestión Agile de Proyectos es un paso más en la madurez de la gestión de proyectos, pero no quiere decir que todo es Agile ni que todo quedará en Agile.
Ah, y Gestión de Proyectos Agile es otra cosa.
Se plantean todas las ideas desde los nexos entre el estándar PMBOK y el marco Agile sabiendo que muchas cosas propias de cada uno y otras cosas que les relacionan están en evolución.
PMBOK como estándar se enriquece con Agile al tomarle prestado instrumental para gestionar proyectos adaptativos y para dar una mirada más efectiva y rica a la gestión de proyectos.
Agile como marco de referencia nacido en el contexto de mejorar el desarrollo de un producto (en concreto de software) ha visto que es víctima de su éxito y ahora ha superado la esfera del desarrollo de productos de software y debe gestionarse, y debe tomar o mirar al mundo de la gestión de proyectos para tomar prestado instrumental de gestión.
Todo el escrito se expone desde una mirada de la actividad profesional de la gestión de proyectos (nunca distinguiendo si estamos ante un proyecto predictivo, adaptativo o híbrido) -no desde la mirada instrumental de usar o aplicar tal o cual herramienta-, y desde una perspectiva epistemológica de la ingeniería de proyectos -alejada de cualquier postura fanática ya sea por el PMBOK o por Agile-. O sea, no quiero entrar en los debates eternos de si PMBOK y gestión de proyectos pueden convivir con Agile y/o Scrum, o si uno es mejor que otro o si uno no sirve de nada frente al otro, o lo que sea.
El cambio en la forma de gestionar proyectos.
Hay dos ideas clave que interesa introducir:
la gestión de proyectos siempre ha tenido la necesidad de gestionar proyectos sabiendo que son mundos en evolución; y,
Agile nació como un conjunto de principios y valores, nada más, y requiere completarse con otras cosas que ha ido tomando de varios sitios y ahora que ha superado sus fronteras desde el mundo del software y ya no todo se limita a hacer productos sino a gestionar recursos, requiere superar sus limitantes conceptuales.
En el 2003, Koppensteiner y Udo, en su artículo Will agile development change the way we manage software projects? Agile from a PMBOK® Guide perspective plantearon una mirada hacia el futuro del desarrollo de software analizando cómo se podría mejorar o enriquecer la gestión del proyecto de producción de software con Agile. Fue un interesante trabajo donde relacionaron las etapas y áreas de conocimiento del PMBOK con lo que podía aportar Agile, los cuales expongo y comento a continuación.
Koppensteiner y Udo desarrollaron tres comparativas muy útiles y que miradas desde la perspectiva del 2021 (y casi 2022) siguen siendo válidas. Esto es simple pues Koppensteiner y Udo en todo momento mantienen una mirada de gestión.
Analicemos lo que plantearon y cómo sería visto al día de hoy.
Estos autores en un primer momento equiparan las cinco (5) etapas, fases o grupos de procesos de la gestión de proyectos (iniciación, planificación, ejecución, control y cierre) con Agile. Hacen un acercamiento general con una tabla donde equiparan PMBOK y Agile. Debe destacarse que es un acercamiento claramente conceptual, es decir, en ordenar acciones Agile según estas cinco etapas o cómo ordenar Agile con una mirada prescriptiva de gestión de proyectos. Esto no está mal, pues realmente ordena el trabajo Agile y no lo deja en el discurso de hagamos sprint.
Luego hacen una relación entre el esfuerzo de las cinco etapas con el trabajo en Agile. Contrastan lo que sería el esfuerzo en cada etapa de la gestión de proyectos con el posible esfuerzo de actividad si se aplica Agile. Es una relación interesante, pero básicamente se compara esfuerzo de actividad laboral e intelectual versus ciclos de trabajo. La comparativa es adecuada, pero excluye la realidad que en cada etapa del PMBOK se pueden hacer muchas ciclos Agile, por lo que el esfuerzo en actividad podría no ser adecuada. Cuidado con asumir que con un ciclo Agile se resuelve todo, pues todo dependerá de la complejidad real del proyecto. Ah, y de que los tipos de actividad sean distintos. Veamos.
Diré que un proyecto es una sucesión de acciones mentales (conceptuales, reflexivas, de investigación, de leer, etc.) y físicas (de hacer acciones físicas como martillar, o de repetir acciones programadas como aplicar estándares, normas o lo que diga el jefe, o sea poco esfuerzo mental). Por supuesto esto es cuestionable y mejorable, pero ayuda a lo que quiero llegar.
Aceptando esta distinción y obviamente aplicando esta mirada, tomada de la ingeniería de proyectos, puedo decir:
de mayor a menor presencia y posible volumen de acciones mentales, las fases serán de iniciación, planificación, cierre, control y ejecución; y,
de mayor a menor presencia y posible volumen de acciones físicas, las fases serán de ejecución, control, planificación, cierre e iniciación.
Destaco que en realidad planificación y cierre van al mismo nivel, pues todo dependerá de si replican o no acciones predeterminadas (consideradas físicas) que otras mentales.
Con esta alusión, simplemente quiero decir que según lo que se deba hacer en cada fase podrá tener niveles de actividad dependiente de muchos factores ligados al trabajo mental o físico, y no necesariamente de si aplicamos, o no, Agile.
Luego estos mismos autores hacen un gran despliegue comparando o equiparando las áreas de conocimiento previstas en el PMBOK con Agile. El resultado nuevamente es un esfuerzo de organizar Agile con una mirada prescriptiva desde el PMBOK. Y obviamente es muy útil al ordenar lo que debe saber un gestor o gestora de trabajo Agile.
En el trabajo de Koppensteiner y Udo queda claro que Agile puede enriquecer el desarrollo de software y más que nada de la actividad profesional de la gestión de proyectos.
No sirve criticar el trabajo de estos autores, pues es una mirada desde la gestión y no desde el desarrollo de productos. Por eso se puede decir que el poner una férula de gestión de proyectos a Agile es acertado en tanto cuanto miremos a Agile como una actividad gestionable, es decir, con limitantes de recursos (los clásicos: alcance-tiempo-coste; y, los postmodernos: cognitivo-mindset-certeza).
Y Agile gana con un posicionamiento de gestión que no tenía o mejor dicho, que no se vio en sus orígenes fundacionales.
Así llegamos a un informe que preparé el el 2010 donde se comparaban herramientas hoy en día consideradas Agile y otras no tan Agile, donde evidenciaba que al momento de analizar un proyecto de software y determinar la forma de llevarlo adelante requería considerar varios parámetros. Y ante estos parámetros se ponían delante varias de las herramientas tal como muestra la siguiente tabla (el artículo lo puedes encontrar en este link).
La tabla, con el tiempo ha mostrado ser útil hasta la fecha.
Llegados al 2017, el PMI, Project Management Institute, sacó el libro Guía Práctica Agile donde se hace el acercamiento formal entre gestión de proyectos desde el PMBOK con Agile. Un aporte altamente atractivo donde Agile queda como un enfoque a aplicar en proyectos adaptativos, o proyectos de alta incertidumbre. Eso es perfecto si vemos Agile como marco, o enfoque, y que enriquece la gestión de proyectos con una perspectiva fresca como la que aporta Agile.
Luego el 2020, la versión 7 del PMBOK (en este link y en este otro link puedes ver cómo se organiza el PMBOK versión 7) aparece y ya introduce literalmente Agile en algunos aspectos aunque es más profuso en introducir a nivel de herramientas de la gestión de proyectos los llamados artefactos y eventos de Scrum.
Básicamente lo que hizo el PMI en la versión 7 del PMBOK fue ampliar el universo de artefactos y herramientas que un gestor o gestora de proyectos puede aplicar.
Podemos cuestionar las clasificaciones del PMBOK, pero veamos en la siguiente tabla un resumen (no extenso) de la propuesta del PMBOK. Cosas que no debes olvidar:
(a) se me puede haber escapado algo desde el trabajo del PMBOK;
(b) hay cosas de Agile que se tomaron de la gestión de proyectos pero que no se sabe/sabía y ahora de nuevo retornan a la gestión de proyectos;
(c) Agile es un compendio de herramientas diversas y muchas cosas tomadas de muchos sitios; y,
(d) Agile gana bastante con lo que hizo el PMBOK pues le muestra otras cosas útiles para que se gestionen mejor los proyectos Agile (no solamente ciclos o procesos Agile).
La siguiente imagen muestra un extracto de cómo el PMBOK presenta estas relaciones. No hace mucho más.
Armando todo.
Aún no todo está escrito pero aquí van dos relaciones claves entre Agile y PMBOK.
La primera imagen muestra cómo pensar un Sprint de Scrum, o si queremos generalizar, un ciclo Agile, ordenando todo desde las cinco fases del PMBOK. Esta perspectiva es útil pues permite a quien esté gestionando un proyecto Agile, ver los sprint (o ciclos) como acciones y recursos. Y si lo unimos a ideas como Scrum de Scrums, con esta visión, se tiene un proyecto Agile gestionado.
PERO esto puede ir más allá.
Claro. Si pensamos los sprint como fases gestionadas, responde bien a la arquitectura de gestión de un proyecto, donde se ejecutan las cinco etapas en diversas morfologías.
Lo otro es mirar las etapas del PMBOK, y sus áreas de conocimiento, y situar el instrumental Agile y Scrum.
Así se puede plantear una relación abierta, no final, ni definitiva, sino más bien una relación móvil, entre instrumental con fases y áreas. Le llamo relación móvil pues señalo donde puedo comenzar a aplicar un instrumento Agile/Scrum pero que puede moverse hacia izquierda-derecha o hacia arriba-abajo. Cada uno o una a su gusto.