Mi revisión de la Agile Practice Guide del PMI

/, PMI/Mi revisión de la Agile Practice Guide del PMI

 

¡No, definitivamente no!, la Agile Practice Guide del PMI no nos va a enseñar a gestionar proyectos de una forma ágil. Pero lo que sí que va a hacer es descubrirnos qué significa ágil y de qué forma podemos abordar el reto de empezar a trabajar de forma ágil en proyectos, independientemente del sector en el que estemos trabajando. La estructura de la guía y el formato que se ha elegido para su redacción contribuyen enormemente a ello.

La Guía se encuentra disponible en varios idiomas, entre ellos el español, aunque como es habitual en el PMI, no se ha puesto el cuidado suficiente en las traducciones y la maquetación es muy mala y los gráficos y tablas permanecen en inglés.

 

 

La Guía tiene este contenido:

  1. Introduction

  2. An introduction to Agile

  3. Life cycle selection

  4. Implementing Agile: creating an agile environment

  5. Implementing Agile: delivering an agile environment

  6. Organizational considerations for project agility

  7. A call to action

Annex

  1. PMBOK Guide mapping
  2. Agile manifesto mapping
  3. Overview of agile an lean frameworks

Appendix

  1. Constributors an reviewers
  2. Attributes that influence tailoring
  3. Agile suitability filter tools

References

bibliography

Glossary

La Guía ha sido elaborada por el Project Management Institute y la Agile Alliance y con la dirección de personas tan prestigiosas como Mike Griffiths por parte del PMI y de Johanna Rothman por parte de la Agile Alliance.

La Guía está orientada solo a:

  • La implementación de prácticas ágiles a nivel de proyecto o equipo.
  • Cubrir los enfoques ágiles más populares.
  • Sugerir qué factores se deben considerar para elegir una propuesta o práctica ágil.

Selección del ciclo de vida

En la tabla siguiente se resumen los cuatro ciclos de vida que contempla la Guía.

 

 

 

 

 

 

 

 

 

 

Me ha sorprendido ver como se ha presentado el ciclo de vida predictivo pues considero que no se ha entendido bien y que además no refleja ni lo que dicen la Guía del PMBoK ni lo que dice PRINCE2, las dos propuestas más populares de gestión predictiva de proyectos. En ambas propuestas se propone una Planificación gradual (rolling wave planning) que implica una toma de requisitos gradual y contempla la entrega de los productos generados en el proyecto durante las distintas fases que componen el proyecto. Efectivamente, se aproxima al ciclo de vida incremental, aunque no es lo mismo. Otro error es asociar el ciclo de vida predictivo a controlar sólo los costes. Me parece increíble este error pues me consta que Mike Griffiths  conoce PRINCE2 y sabe que en este método la Meta es una gestión del valor que los productos del proyecto generarán.

En este capítulo se describen las características de cada uno de los cuatro ciclos de vida propuestos y también propone la posibilidad de utilizar ciclos de vida híbridos de modo que en un proyecto podamos utilizar distintos ciclos de vida en función del momento en el que nos encontremos o incluso podamos utilizar un ciclo de vida predictivo para gestionar el proyecto y un ciclo de vida ágil para que los equipos de desarrollo construyan los productos. Este último caso es el que nosotros hemos propuesto en algunos casos con PRINCE2 donde las capas de dirección y gestión del proyecto siguen un ciclo de vida predictivo y en la capa de entrega se utiliza Scrum.

Implementar Ágil. Crear un entorno ágil

En este capítulo se expone la necesidad de cambiar el mindset, la mentalidad, de los equipos y de los líderes. Para ello es necesario pasar hacía un Servant Leadership de modo que los líderes faciliten el éxito de los equipos.

Se expone también las características que deben tener los equipos ágiles para que sean exitosos:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Implementar Ágil. Entregar en un entorno ágil

Me ha gustado mucho que además de hacer referencia al Acta de constitución del proyecto resalte la importancia del Acta de constitución del equipo (team charter).

El Acta de constitución del proyecto, agile project charter, debe responder a las siguientes preguntas:

  • ¿Por qué estamos haciendo este proyecto? Esta es la visión del proyecto
  • ¿Qué beneficios y cómo los va a proporcionar? Esto puede ser parte de la visión del proyecto o del propósito del proyecto
  • ¿Qué significa terminado (done) para el proyecto? Estos son los criterios de entrega del proyecto
  • ¿Cómo vamos a trabajar juntos? Esto explica el flujo de trabajo previsto

El Team charter, que no tiene que ser algo formal y documentado, debería permitir consensuar lo siguiente:

  • Valores del equipo, tales como ritmo sostenible y horario de trabajo
  • Acuerdos de trabajo, tales como el significado de Listo (ready), Hecho (done), respecto del timebox, uso del WIP (work-in-process), etc.
  • Reglas básicas (ground rules), tales como que solo una persona habla a la vez en una reunión y
  • Normas del grupo, tales como el modo en el que se gestiona el tiempo en las reuniones.

Adicionalmente, en este capítulo se expone cómo trabajan los equipos y se describen las principales prácticas, aunque sobre todo Scrum y cómo se mide en los proyectos ágiles. Aunque lo que he encontrado más interesante has sido la relación de Puntos de dolor y posibles soluciones, sobre todo porque ofrece una relación de problemas muy comunes en la adopción de prácticas ágiles.

Consideraciones organizativas para la agilidad del proyecto

En este capítulo se tratan diversas cuestiones, todas ellas relacionadas con la importancia del entorno para conseguir el éxito en la adopción ágil: Change Management, modelos de contratación y papel de la PMO.

Resalta la importancia de incorporar prácticas de Change Management y sugiere que toda adopción ágil debe realizarse desde una gestión del cambio en la organización, algo con lo que estoy totalmente de acuerdo. Para ello hace referencia a la publicación del PMI Managing Change in Organizations: A practice Guide de la que pronto publicaremos un resumen.

Anexo A3. Visión general de los marcos de trabajo ágil y lean

A los que sabéis un poquito de ágil os lo podéis saltar. Se hace una descripción tan somera de los marcos de trabajo que resulta muy difícil entender en qué consisten. Por cierto, me sigue resultado increíble que se incluya la referencia a Crystal. Por favor, si alguien ha leído algunos de los libros donde se describe o si alguien ha utilizado alguna vez Crystal que me escriba.

Apéndice X2. Atributos que influyen en personalización

En este apéndice se proporciona una guía a alto nivel sobre cuándo y cómo personalizar los marcos de trabajo ágiles. Se puede utilizar para determinar las circunstancias que podrían provocar el cambio o la introducción de nuevas técnicas, ofreciendo algunas recomendaciones.

La Guía considera situaciones como las siguientes:

  • Equipos de proyecto muy grandes
  • Equipos dispersos
  • Requisitos estables y procesos de construcción
  • Los equipos están en silos funcionales dentro de organizaciones funcionales
  • etc.

Son situaciones muy comunes y aunque las recomendaciones son a muy alto nivel nos dan idea de con qué retos nos podemos encontrar y cómo afrontarlos.

Apéndice X3. Herramientas para determinar la idoneidad de ágil

Aunque a mi juicio se queda un poco pobre, es una buena ayuda para entender qué debemos considerar para determinar cómo de fácil o difícil será aplicar ágil en un proyecto. Podéis encontrar más información sobre este asunto y mucho más interesante en estos dos enlaces:

El modelo de evaluación que nos propone esta Guía se basa en tres categorías:

  • Cultura
  • Equipo
  • Proyecto

y para cada una de las categorías se proponen una sería de cuestiones que se deben evaluar de 1 a 10 puntos.

El resultado es un radar como el que se muestra a continuación extraído de la Guía.

 

Considero que el PMI ha dado un gran paso con la elaboración de esta Guía la cual significa un reconocimiento de la importancia que está tomando la Agilidad en los proyectos y en las organizaciones.  Es muy valioso que la Guía no se haya centrado en la agilidad para el desarrollo de software y que su lectura sea válida e interesante para profesionales de cualquier sector.

Espero que gracias a esta iniciativa cada vez haya profesionales de sectores más diversos que consideren la Agilidad como una opción que puede mejorar el resultado de sus proyectos, así como la satisfacción de sus empleados y proveedores.

By | 2018-01-30T04:42:20+00:00 enero 18th, 2018|Agile, PMI|0 Comments

Leave A Comment