PMP y Agile

PMP y Agile: una poco de sentido común

Hace unos días se celebró el centenario de la publicación de la Teoría General de la Relatividad por Albert Einstein. Hace también unos pocos días asistía a la Conference Agile Spain 2015 (CAS2015), el evento anual sobre agilismo que se celebra en España. Y, aunque son dos cosas totalmente diferentes, guardan dos intrigantes paralelismos:

  • En ciencia, es muy difícil romper con las creencias establecidas, con las teorías de siempre. Con el siempre ha sido así. Sólo la gente más joven, sin temor a romper esos juicios o ideas preconcebidas son capaces de proponer soluciones distintas a los problemas de siempre. Romper el statu quo.
  • Las teorías físicas no permiten explicar el universo entero (no al menos en la práctica). Mientras la teoría de la relatividad permite explicar el universo a gran escala, no es necesaria para nuestro día a día, no digamos ya a escala subatómica. Los físicos no desisten en buscar una teoría global pero, aunque exista, en la práctica, no sería práctica a determinadas escalas (¡como la nuestra!)

Llevadas estas ideas a la gestión del proyectos, me resultan tristemente familiares con PMP y Agile:

  • Percibo cierto rechazo mutuo desde algunos sectores del PMPismo (o PRINCE2ismo, o lo que se quiera)y el Agilismo. En vez de entender que PMP y Agile son marcos de referencia para la ejecución de proyectos, basados en buenas prácticas, los “viejos” ignoran lo “nuevo”, y los “nuevos” lo “viejo”. Y vaya por delante que Agile no es tan nuevo ni PMP tan viejo.
  • Cada proyecto requiere una aproximación distinta. Hay proyectos totalmente inconcebibles desde una perspectiva agile, y proyectos en los que la concepción clasicista naufragaría. Y proyectos en los que conviene reflexionar si conviene usar uno u otro. Como sucede en la física, las mismas leyes, los mismos paradigmas, no permiten tener soluciones prácticas a todos los problemas. Las leyes que aplicamos al movimiento de un coche por una carretera y al de una partícula moviéndose a velocidad cercana a la de la luz no son las mismas.

Ya sé que se ha hablado mucho de este tema, de las discrepancias entre ambos mundos (que, en mi opinión, no distan tanto entre ellos). En este sentido, sé que estoy descubriendo la sopa de ajo. En el Laboratorio de las TI ya nos avisaban hace algún tiempo que lo importante es el objetivo. Pero me sorprende la falta de discrepancia interna, de diálogo intestino, dentro del agilismo y el PMPismo.

Tigres y leones, todos quieren ser los campeones

Empezar hablando de la teoría de la relatividad y pasar, así sin más, a una canción infantil de Torrebruno tiene su delito. Pero si pasas o rondas los 40 años probablemente recuerdes de tu infancia la canción Tigres, Leones, todos quieren ser los campeones. Y, sintiendo mucho el giro en la narración, me recuerda mucho a lo que se está viviendo en muchos sectores de la gestión de proyectos.

PMP y Agile

Esto no es una competición, dos equipos, tigres y leones, aunque a veces parece que sea así. Cada proyecto, cada contexto, requerirá una aproximación u otra. O una mezcla de ambas.

En mi vida profesional he asistido a numerosos congresos en los que había debate real y diferencia de opiniones, desde el respeto y pese a la diversidad de intereses.

Tengo la sensación creciente de que el mundo del software está especialmente polarizado.

En el CAS2015 se respiraba agilismo por los poros. Pero quizá demasiada homogeneidad de ideas. Muchas charlas sobre lo bien que ha funcionado la adopción de Agile en algunas empresas, con sus dificultades y grandes ideas, pero nada sobre aquellas en las que ha fallado (por los motivos que sea). Y estoy seguro que entre los defensores de PMP sucedería algo parecido.

He estado 14 años dirigiendo proyectos según los estándares de desarrollo de software totalmente alineados y compatibles con el PMP. Y llevo otros dos años más gestionando proyectos tanto ágiles como clásicos.  Y puedo asegurar que no vi ni oí nada en CAS2015 que no me gustara o deseara aplicar yo mismo en mi día a día. Incluso en proyectos no ágiles.

PMP y Agile razonable

Por supuesto que no son dos mundos tan dispares, y hay excepciones. Gente que, como yo, viene del mundo de la gestión clásica, intenta encajar las buenas prácticas en metodologías como SCRUM. El propio PMI certifica en agilismo (el PMP-ACP, Agile Certified Practitioner).

Recíprocamente, citaré como ejemplo la keynote de Leo Antoli en el CAS2015, poniendo en solfa muchas creencias del mundo de desarrollo SW. Leo, miembro fundador y primer secretario de la asociación Agile-Spain (poco sospechoso, por tanto, de PMPismo) empezó la charla definiéndose no como agilista, sino como alguien a quien le gusta hacer software. Su bio en Twitter lo deja claro: Perpetual Learner.

PMP y Agile: Keynote de Leo Antoli
Momento de la charla de Leo Antoli en CAS2015

En cualquier caso (y muy al hilo de la charla de Leo Antoli arriba citada), cabe plantearse la siguiente cuestión.

¿Cuántos proyectos clásicos existen que hagan todo lo que dice PMP? ¿Y cuántos ágiles que cumplan todo lo que requiere un SCRUM de libro?

Pocos, muy pocos. Hay muy pocos proyectos puristas en uno y otro lado. Por la simple razón de que la realidad se termina imponiendo.

El papel lo aguanta todo pero la realidad es  muy tozuda.

Los que critican agile por verlo irrealizable, desconocen la realidad de los proyectos ágiles. Los que critican PMP por ser demasiado rígido cometen exactamente el mismo error.

¿Adios, SCRUM?

Puestos a hablar de buenas prácticas que conducen a excelentes resultados, quizá no debamos perder de vista el mundo del desarrollo de software libre (open source). Recomiendo la lectura del artículo de Enrique Dans ¿Adios, SCRUM? y el advenimiento de otro paradigma: el Open Development Method.

¿Significa eso que ODM es el nuevo paradigma de la gestión y supera tanto a PMP/PRINCE2/… como a Agile? Rotundamente no. ODM puede ser imprescindible en desarrollo de proyectos de código abierto, interesante en algunos proyectos empresariales (de ahí que se esté formalizando) y aportar, en cualquier caso, un conjunto de buenas prácticas de clasicistas y agilistas deberán tener la capacidad de analizar y, llegado el caso, incorporar a sus procesos de gestión.

Conclusiones

Ni los que tenemos más años de experiencia en metodologías clásicas (PMP, PRINCE2, …) somos unos viejos académicos pasados de fecha, ni los practicantes de Agile unos frikis de garaje. Los métodos clásicos tienen un amplio rodaje y mucho que aportar. Las metodologías ágiles como SCRUM tienen ya un poso de madurez importante  y muchísimos casos de éxito a sus espaldas, y no deben ser ignoradas.

Mientras, el advenimiento de paradigmas como el Open Development Method nos recuerda que esto no es una historia de buenos y malos. Es una historia de alcanzar los objetivos de la manera más sensata y eficiente posible.

En resumen, más ganas de aprender del otro. Más espíritu crítico para ser consciente de que lo que hace uno no tienen por qué ser, necesariamente, lo mejor.

Print Friendly, PDF & Email

15s comentarios

  1. Yo voy a tirar por la calle de enmedio con un modelo ágil-lean (agilín para los amigos) que publico el próximo lunes.

    Todas estas disquisiciones habría que llevarlas a la pequeña empresa para ver si allí tienen alguna utilidad.

    Ah! El software ya tiene un sentido más amplio del ámbito informático.

  2. Interesante artículo, aunque es importante dejar claro que “PMP” no es un marco de referencia, es una certificación en Dirección de Proyectos. El marco de referencia en el cual se basa la Certificación PMP es “La Guía del PMBOK”, y es a este marco de al que habría que comparar con otros (recordando que no es prescriptivo, sino un conjunto de mejores prácticas que cada organización o proyecto debe adecuar a su realidad).

    Y sí, pueden convivir perfectamente, si se entiende cómo y dónde aplicar cada uno. Actualmente llevo un proyecto donde hemos combinado con éxito ambos enfoques, métodos clásicos para gestionar el proyecto (principios de La Guía del PMBOK) y ágiles para la construcción del producto (SCRUM).

    1. Totalmente de acuerdo José. te agradezco la puntualiación. El uso de la palabra PMP es en cualquier caso intencionado “por claridad” (a costa de “rigor”), porque creo que se entiende mejor (al menos entre los “agilistas”).

      Pero llevas toda la razón del mundo.

      ¡Gracias por aportar!
      8)

  3. No puedo estar más de acuerdo contigo. Ambas aproximaciones a la gestión de proyectos no están enfrentadas en absoluto, de hecho pueden y deben coexistir según las especificidades del proyecto, el contexto y la cultura empresarial. Y esta unión cobra especial importancia cuando se trata de escalar metodologías ágiles en grandes empresas.

    Yo he vivido de primera mano como gestor de proyecto una experiencia en France Telecom / Orange en Toulouse (Francia) en la que claramente la implementación de una metodología SCRUM “de libro” fracasó y en la que tuvimos que aplicar un mix de Agile SCRUM/Waterfall PMBOK para sacar el proyecto adelante. La solución pasó por seguir trabajando como equipo auto-organizado y multifuncional, con sprints, daily meetings y sprints reviews, con TDD, CD y CI, pero sin Product Owner, con requisitos y planes de prueba, así como gestión de costes y riesgos, según PMBOK.

    Para mi fue una gran experiencia y creo que es aplicable en diferentes contextos adaptándolo en cada caso a la madurez ágil de cada empresa. Al final, lo importante, como bien has resaltado en tu artículo, no son las herramientas sino el cumplimiento del objetivo del proyecto de forma eficiente.

    1. ¡Muchas gracias Bienvenido!

      Ese es el tipo de experiencias al que me refiero. Uno va con toda su voluntad a aplicar SCRUM “de libro”, y fracasa. Necesita adaptaciones, y muchas veces vienen del mundo PMBOK. Recíprocamente sucede algo parecido, aunque es sabido que justamente al principio del proyecto es cuando tienes que planificar todo (en métodos, procedimientos, herramientas, …)

      Lo de la falta de Product Owner es un clásico. Échale un vistazo a mi post sobre los profesionales del escapismo en el agilismo 🙂 (http://www.elmiracielos.com/gestion/los-mayores-enemigos-del-agilismo-los-profesionales-del-escapismo/)

      ¡Muchas gracias por aportar!
      8)

  4. Me queda la duda de cual es tu opinión aquí acerca de los contextos en donde aplica una visión y no la otra. IMHO sin esa definicion es dificil distinguir en tu publicacion si hablas desde una intencion de ser politicamnete correcto o basado en experiencia concreta y solida.

    En mi experiencia el modelo PMBOk nace en proyectos donde el problema es conocido y la la receta de la solución es también conocida, aunque tenga muchas partes y piezas que ensamblar. Por ejemplo aquí califica un proyectos de construccion de un edificio común. En donde este modelo ya no cumple es cuando se debe crear una nueva solución (que es en todos los proyectos de software y muchos otros del ambito de la innovacion) o en aquellos en donde incluso el problema a resolver no está tan claro (startups)

    Ahora bien, cuando PMI asume el rol de certificar en Agilidad para mi eso nunca dejo de ser mas que una maniobra comercial y es lo mismo que un ingeniero de estructuras le enseñe a un emprendedor tecnologico como hacer su oficio: simplemente no funciona. Y tampoco aspiro a que los Agilistas le tengan que enseñar al primero como hacer su trabajo.

    Si están interesados en profundizar en este tema los invito a ver esta charla https://www.youtube.com/watch?v=5waUjcqaFvY

    1. ¡Muchas gracias Agustín!

      Hay varios puntos sumamente interesantes en tu comentario.

      En primer lugar, el objetivo del post era una reflexión sobre los mundos Agile y PMBOK: no pueden ser disjuntos, sino que pueden y deben enriquecerse mutuamente,. Tanto en buenas prácticas como por el hecho de que la mayoría de proyectos pueden soportar una aproximación híbrida entre ambas.

      Es cierto que empecé a escribir en el post sobre qué entiendo que se adapta mejor a PMBOK y qué a Agile. Entenderás que quedaba demasiado largo, y pretendo hablar de ello en un post futuro. Vaya por delante que el tema es polémico, porque si cada uno tiene un sesgo personal y profesional en su visión de PMBOK y Agile, a la hora de hablar sobre elegir, y no digamos de “mezclar” puede pasar cualquier cosa.

      En cualquier caso, te adelanto brevemente mi punto de vista.

      Elijo Agile cuando:

      1) Hay incertidumbre sobre el alcance del proyecto
      2) Hay necesidad de entregas tempranas y/o frecuentes (ej. presión del time-to-market, continuas evoluciones, …)

      Sí estoy de acuerdo en que en construcción de edificios comunes PMBOK es suficiente y necesario, pero discrepo con tu punto de vista del SW. He estado más de 14 años trabajando en desarrollo de SW para el sector aeroespacial. Si desarrollas software embarcado en un avión o un satélite, olvídate de Agile. Aunque “funcione”, es imposible que pase una sola certificación porque está sujeta a procedimientos muy sólidos de desarrollo de software crítico (hay quien trabaja en esta línea, agile para software crítico, pero el tema está muy inmaduro). Te puedo poner ejemplos de simuladores de datos en los que no tiene cabida Agile y sí PMBOK. Y, por supuesto, viceversa: herramientas software que es mejor construir como Agile porque:

      1) El cliente (¿Product Owner?) no tiene claras sus prioridades
      2) Limitaciones presupuestarias
      3) Incertidumbre en la implementación (compartir riesgos de costes)

      Y muchos casos más.

      Como ves se puede tirar del hilo muuuuuuuucho más, pero lo dejo para otro post.

      Muchísimas gracias por el enlace al vídeo. Lo verés con más detalle y comentaré en el mismo.

      ¡Muchas gracias por aportar!
      Ángel

  5. No le veo sentido a que haya rivalidad… ambos PMP y Agile son un complemento excelente para administración de proyectos. Es un asunto de adaptación, en el que hay mucha resistencia al cambio y hasta “miedo” al agilismo…

    1. Muchas gracias Christian!

      Esa es precisamente la idea del post: reivindicar que ambos son compatibles y que es una cuestión de decidir cuál de ellos se adapta mejor a cada circunstancia.

      ¡Muchas gracias por comentar!
      8)

  6. Estimado Angel,
    He leido con mucho agrado tu post y lo veo muy interesante, tengo algunas consultas que espero puedas aclarme:
    1. Hablas acerca de intentar encajar las buenas prácticas en metodologías como SCRUM. Es que estamos dando por entendido que si es posible y real poder combinar estas dos maneras de trabajar proyectos de software.
    2. Que tan complejo o distante esta la fución de estos dos marcos de trabajo, que se encuentran indicados en un unico documento del propio PMI (indicado en el PMP-ACP, Agile Certified Practitioner).

    Muchas gracias por tu respuesta.

    1. Hola Marco,

      En primer lugar, muchas gracias por tu feedback. Me alegra enormemente que el post haya resultado de tu interés.

      En primer lugar, sí es posible (¡y recomendable!) acercar ambos mundos incorporando buenas prácticas de SCRUM a modelos waterfall y viceversa. De hecho resulta, en términos prácticos, más sencilla ésta aproximación que el querer pasar de uno a otro.

      Hay muchos artículos en Internet que dan ideas sobre cómo hacer esto. En mi experiencia, depende mucho del sector y de la cultura de empresa, por lo que no hay una guía que diga haz esto, esto, esto … Pero ideas puede haber muchas.

      Por ejemplo, yo he trabajado la mayor parte de mi vida con proyectos en cascada (waterfall). Hay ideas básicas de SCRUNM que se pueden incorporar, como las retrospectivas (en vez de esperar al cierre de proyecto para las lecciones aprendidas, donde ya hay poco margen). La gestion del calendario también me parece más mantenible en agile que en waterfall. Puedes seguir teniendo tu megacalendario en ej. MSProject, pero intentar incorporar buenas prácticas de SCRUM. Lo mismo sucede con gestión de requisitos.

      Recíprocamente, me gusta más la gestión de riesgos y stakeholders que se hace en modelos en cascada. La dinámica de los riesgos en SCRUM es inherente al modelo, pero en mi modesta opinión se diluye un poco sobre todo en el caso de riesgos compuestos, o riesgos que incluyan al cliente. No es realista hacer recaer demasiadas cosas sobre la cabeza de los product owner.

      Respecto a la segunda pregunta, es un poco filosófica, pero sinceramente creo que no están tan alejadas. Ambos son marcos de referencia que incluyen buenas prácticas para el desarrollo y gestión de proyectos. Marcos como PMI basculan más del lado de la gestión, mientras que agile va en consonancia con la lógica de desarrollo y actividades de proyecto. Obviamente el Project Manager elige una aproximación u otra en función de las características del proyecto. Y obviamente puede incorporar las buenas prácticas que desee del otro, adaptándolas a la realidad del proyecto.

      Es un tema largo de explicar, y muy sensible a la cultura de empresa y al entorno. Nosotros tenemos secciones enteras que hacían waterfall, fueron incorporando agile, y ahora son 100% agile. Y secciones en los que agile simplemente no tiene cabida, más que en el sentido que he comentado (adoptar buenas prácticas).

      Espero haber arrojado algo de luz sobre el tema.

      ¡Gracias por comentar!
      8)

¡GRACIAS POR COMENTAR!