CERTIFICACIÓN AGILE HYBRID PROJECT PRO

Consciente de la importancia que está teniendo últimamente en materia de proyectos el movimiento de mezclar elementos de las metodologías predictivas o waterfall, agile, Six Sigma y otras, el PMI ha lanzado una nueva certificación orientada a cubrir esta necesidad formativa.

La micro-credencial ágil / híbrida se alinea con la Guía para el cuerpo de conocimiento de la gestión de proyectos, la Guía del PMBOK, (que ya está en su versión 7) y que es el estándar global preeminente para la gestión de proyectos y que proporciona las prácticas fundamentales de la profesión.

Según el PMI “Los poseedores de la certificación Agile Hybrid Project Pro Micro-Credential han demostrado su amplio conocimiento de conceptos, tareas y técnicas de gestión de proyectos ágiles / híbridos que son aplicables en prácticamente cualquier industria. Los poseedores pueden hablar y comprender el lenguaje global de la gestión de proyectos ágiles / híbridos. Los poseedores han demostrado el conocimiento y las habilidades necesarias para gestionar los planes, el alcance, las partes interesadas, los riesgos, los presupuestos, el cumplimiento, los recursos, la resolución de problemas y la entrega de valor del proyecto.”

La certificación  Project Pro Micro-Credential se está introduciendo para ayudar a los gerentes de proyectos tradicionales, titulares de la certificación PMP existentes, gerentes de proyectos con conocimientos ágiles / híbridos y / o experiencia, para alinearse con los últimos estándares de la industria.

Y es que, como ya vimos en la entrada correspondiente a la certificación Google de Project Management, es ya un hecho que, en lugar de seguir una sola metodología para la gestión de un proyecto, lo más adecuado es estudiar tanto las características del proyecto como las peculiaridades de la empresa y decidir qué es lo más adecuado para lograr el éxito.

Se trata de un movimiento imparable que se ha convertido en tendencia. Mal que le pese a los apóstoles del agilismo o del waterfall puros, muchos responsables de proyectos se han dado cuenta, a través de la experiencia, de que el éxito de un proyecto depende mucho de la cultura de la empresa y que el uso de prácticas o artefactos de las diferentes metodologías puede ayudar enormemente a llevar a buen fin un proyecto.

Ya nadie duda que las daylies que provienen del agilismo ayudan mucho a mejorar la comunicación del equipo y fomentan la transparencia.  Y lo mismo ocurre con las “Retrospectivas“, que proporcionan un feedback excelente acerca de lo que ha sucedido en una fase, iteración o proyecto. Por otra parte, el Business Case de la metodología Prince2 se ha demostrado que proporciona claridad en la definición de los objetivos del proyecto y la búsqueda de rentabilidad o de valor añadido. Es un hecho que muchos proyectos hacen un kickoff para iniciar sus proyectos y completan un Project Charter para definir lo que el proyecto debe cumplir.

A continuación, muestro un resumen de algunos de los enfoques de gestión de proyectos que pueden componer el enfoque híbrido:

  • Predictiva o Waterfall es una metodología tradicional en la que las tareas y fases se completan de manera lineal y secuencial, y cada etapa del proyecto debe completarse antes de que comience la siguiente. El Project Manager es responsable de priorizar y asignar tareas a los miembros del equipo. En el enfoque predictivo, los criterios utilizados para medir la calidad están claramente definidos al inicio del proyecto. Es ideal para proyectos en los que los requisitos están claros desde el principio (lo que no suele ser muy normal).
  • Agile implica fases cortas de trabajo colaborativo e iterativo con pruebas frecuentes y mejoras implementadas regularmente. Algunas fases y tareas ocurren al mismo tiempo que otras. En los proyectos ágiles, los equipos comparten la responsabilidad de gestionar su propio trabajo. Scrum y Kanban son ejemplos de marcos ágiles, que son enfoques de desarrollo específicos basados ​​en la filosofía Agile.
  • Scrum es un marco ágil que se enfoca en desarrollar, entregar y mantener proyectos y productos complejos a través de la colaboración, la responsabilidad y un proceso iterativo. El trabajo lo completan equipos pequeños y multifuncionales dirigidos por un Scrum Master y un Product Owner  y se divide en Sprints cortos con una lista seleccionada de entregables.
  • Kanban es tanto un enfoque ágil como una herramienta que proporciona retroalimentación visual sobre el estado del trabajo en progreso mediante el uso de tablas o gráficos Kanban. Con Kanban, los gerentes de proyecto usan notas adhesivas o tarjetas de notas en un tablero Kanban físico o digital para representar las tareas del equipo con categorías como “Por hacer”, “En progreso” y “Listo”.
  • Prince2 es una metodología de gestión de proyectos que se plantea sean realizados entre otras actividades considerando 7 temas: la Calidad, el Cambio, la estructura de roles del proyecto (Organización), los planes (Cuánto, Cómo, Cuando), el Riesgo y el Progreso del proyecto, justificado por un Business Case (o necesidad del negocio) que es la que evidencia la realización de ese proyecto.
  • Lean utiliza la herramienta de calidad 5S (clasificar, ordenar, limpiar, estandarizar, disciplina) para eliminar ocho áreas de desperdicio, ahorrar dinero, mejorar la calidad y agilizar los procesos. Los principios de Lean establecen que puede hacer más con menos al abordar las disfunciones que generan desperdicio. Lean implementa un sistema de programación Kanban para administrar la producción.
  • Six Sigma implica reducir las variaciones asegurando que los procesos de calidad se sigan en todo momento. El método Six Sigma sigue un enfoque de mejora de procesos llamado DMAIC, que significa definir, medir, analizar, mejorar y controlar.
  • Lean Six Sigma es una combinación de enfoques Lean y Six Sigma. A menudo se utiliza en proyectos que tienen como objetivo ahorrar dinero, mejorar la calidad y avanzar rápidamente en los procesos. Lean Six Sigma también es ideal para resolver problemas complejos o de alto riesgo. La herramienta de calidad 5S, el proceso DMAIC y el uso de tableros Kanban son todos componentes de este enfoque.

El examen de certificación se basa en la aplicación de los siguientes principios y conceptos: 

  • Manejar conflictos y liderar un equipo
  • Apoyar el desempeño del equipo, empoderar a los miembros del equipo y a las partes interesadas
  • Abordar y eliminar impedimentos, obstáculos y bloqueos para el equipo
  • Colaborar con las partes interesadas e involucrar a las partes interesadas
  • Desarrollar un entendimiento compartido, involucrar y apoyar a equipos virtuales
  • Ejecute el proyecto con la urgencia necesaria para ofrecer valor empresarial
  • Gestionar comunicaciones, evaluar y gestionar riesgos
  • Planificar y administrar el presupuesto, el cronograma, la calidad de los productos / entregables, el alcance, los cambios y los problemas del proyecto
  • Planificar y gestionar el cumplimiento del proyecto
  • Evaluar y entregar los beneficios y el valor del proyecto

Los dominios en  los que se basa el examen son los siguientes:

  1. People,
  2. Process
  3. Business Environement.

La siguiente tabla identifica la proporción de preguntas de cada dominio que aparecerán en el examen:

Por último comentar que el examen de certificación se puede realizar “on line” en modo “unproctored” y consta de 60 preguntas, que se deben completar en 75 minutos. Superar el examen proporciona 13 PDUs válidos para el mantenimiento de los poseedores de la certificación PMP.

Más información:

LIBRO AGILE PRACTICE GUIDE

Título original: Agile Practice Guide

Autores: PMI + Agile Alliance

Editorial: Project Management Institute, año 2017

Páginas: 210

Idioma: inglés

ISBN: 978-1628251999

Palabras clave: Proyectos, Metodología, Agile, PMP, Project Management, Predictiva

Interesante este libro escrito conjuntamente entre PMI y Agile Aliance. Un apunte, si formas parte de PMI y pagas las cuotas anuales de socio, puedes descargar este libro de forma gratuita en formato pdf desde la web de www.pmi.org 

Y da que pensar que el PMI (que ya cuenta con una certificación especifica en materia de agilidad) da por sentado que la agilidad es una metodología que ha llegado para quedarse durante mucho tiempo entre los Project Managers.

Dado que la agilidad se ha expandido a otros ámbitos de desarrollo, el enfoque de este libro se expande más allá del mundo de desarrollo de software

Esta guía está dividida en siete secciones.

1. Introducción

¿Por qué un manual de este tipo ahora? Porque la agilidad es una metodología que busca proporcionar al cliente una inmediata entrega de valor, a través de varias interacciones y esto es muy valorado ahora, pues las empresas buscan ser competitivas orientándose a la experiencia que obtiene el usuario. Son adecuadas para manejar la disrupción.

Los autores comentan que no está en alcance de este libro estudiar cómo extender la agilidad entre toda la organización sino extenderla a uno o varios proyectos. Es una lástima, porque si la organización no cambia es difícil que los proyectos ágiles tengan éxito.

2. Introducción a la agilidad

  • Esta sección trata fundamentalmente del origen de la agilidad y de los principios que lo sustentan
  • la justificación de la agilidad se basa en que el manejo de la incertidumbre es algo que las metodologías predictivas no manejan bien, pues no están orientadas a aceptar el cambio, la complejidad y el riesgo.
  • El manifiesto ágil de desarrollo de software del año 2001 puso por encima de todo a las personas por encima de los procesos. Se crearon cuatro valores y doce principios
  • Me llama la atención la referencia a la relación entre Lean/agile, pero el enfoque de ambos es diferente
  • Interesante la matriz de complejidad de Stacey. Un proyecto puede empezar en un sitio de la matriz y acabar en otro.

Resumiendo, los proyectos más adecuados para ser abordados por la metodología agil son aquellos que:

  • Requieren de investigación
  • Tienen altas posibilidad de sufrir cambios
  • Presentan requerimientos desconocidos o poco claros
  • Tienen un propósito difícil de describir

3. Selección del ciclo de vida

Es la parte más interesante del libro, con diferencia.

Habla de los cuatro tipos de ciclos de vida de los proyectos: predictiva, iterativa, incremental y ágil y de sus características.  Estoy de acuerdo con su apreciación de que no hay un ciclo de vida perfecto para todos los proyectos:

  • Los ciclos de vida predictivos se benefician de entornos en los cuales los requerimientos están bien definidos y marcados (ej. un proyecto fruto de una exigencia legal). Su punto débil son los cambios y que no entregan valor hasta el final del proyecto.
  • Los ciclos de vida iterativos son beneficiosos si existe una alta complejidad, si hay cambios frecuentes o si el alcance depende de diferentes interesados. Están optimizados para el aprendizaje. Un ejemplo son las “refactorizaciones” de software.
  • Los incrementales se orientan a la velocidad de la entrega. Se entregan frecuentes y pequeños entregables. Un ejemplo puede ser completar un aplicativo de software mediante el desarrollo de diferentes módulos. O mostrar cómo quedaría una habitación en el proyecto de construcción de un edificio.
  • Los agiles son excelentes aproximaciones cuando se espera una gran cantidad de cambios en un proyecto. La diferencia de ágil con los ciclos interactivos e incrementales es que estos últimos proporcionan feedback para la siguiente parte del proyecto, pero, sin embargo, en proyectos ágiles, la entrega incremental descubre ocultos o requisitos incomprendidos. A su vez, los ciclos agiles pueden basarse en iteraciones o en flujos de trabajo. los ciclos ágiles combinan aproximaciones incrementales e iterativas para entregar valor de forma frecuente al cliente.
  • Como síntesis de todo lo anterior surgieron los ciclos de vida híbridos, que son los que se combinan para obtener ciertos objetivos. Por ejemplo, se puede trabajar en las primeras fases de un proyecto con metodologías ágiles (si se necesita investigación) y luego pasar a una metodología predictiva (si se debe cumplir una certificación). O combinar ambas metodologías según para qué aspectos (a mí esto me parece más complejo). Hay muchas combinaciones posibles.
  • Este apartado es tan interesante y está descrito a tan alto nivel, que necesita más desarrollo.

4. Implementando ágil: Creando un entorno ágil

Mencionan que un entorno ágil exige un líder “sirviente”, (que haga de facilitador del éxito del equipo), en lugar de un líder tal y como se describe en los proyectos predictivos. Este tipo de lider debería de pasar de “gestionar” la coordinación a “facilitar” la coordinación.

No se ha tocado la parte correspondiente al “mapeo” de roles entre metodologías predictivas/ágiles. Otro tema interesante pendiente.

Y le impone al líder “sirviente” una tarea adicional, tratar de remover los impedimentos organizativos al equipo del proyecto que pudieran hacer de “cuello de botella”. Sinceramente pienso que si la organización no se orienta a la agilidad, es bastante complejo que el líder sirviente pueda solucionar por sí solo este problema.

Precisamente y dado que el papel del project manager no se contempla dentro de la agilidad, pues según el PMOK 6 son los encargados de obtener los resultados del proyecto y esta responsabilidad en ágil se distribuye por igual en el equipo del proyecto, propone que hagan de lideres “sirvientes”, es decir, que sirvan al equipo del proyecto, allanando su camino.

Si el enfoque predominante es ágil, entonces el papel del PM cambia radicalmente y debe orientarse hacia el liderazgo servil que requiere este tipo de enfoque.

Se habla de los atributos de los equipos agiles exitosos. Comenta que a los equipos ágiles se les debe evitar el coste que supone la “multitarea” de trabajar en varios proyectos de forma simultánea, así como que idealmente deberían de compartir el mismo espacio físico. Se alerta contra el peligro de querer trabajar en forma de “mini waterfalls” que es lo que sucede si se presupone que ya se tienen todos los requerimientos y ya se puede hacer todo el diseño (por ejemplo) o todo el desarrollo. El equipo se dará cuenta de que esa asunción en el mundo ágil no es válida.

Los tres roles que menciona son: product owner, equipo multifuncional y facilitador del equipo (llámese scrum master, project manager o team coach). Apunta que lo ideal es contar con especialistas de tipo “T”, que son los que complementan ser expertos en una materia con conocimientos en otras areas.

Alerta acerca de evitar “silos” en la empresa que impidan que la comunicación fluya en el equipo.

5. Implementando ágil: entregando en un entorno ágil

Todo proyecto necesita un acta de constitución donde se defina el proyecto. Pero esto no es suficiente n un entorno ágil. También necesita una visión, un propósito y unas normas de cómo trabajar en equipo.

Las prácticas agiles más importantes son:

  • Retrospectivas. Permite al equipo aprender, mejorar y adaptar su proceso. No es necesario que sea al final de una iteración de dos semanas. se puede solicitar en cualquier momento. Busca las causas raíz de los problemas sufridos y se desarrolla un plan de acción para solucionarlos.
  • Preparación del backlog (lista del trabajo presentado en forma de historias de usuario). No es necesario tener todo el trabajo que el proyecto requiera sino solo el que se va a desarrollar en siguiente sprint o iteración. Esta es tarea del product owner
  • Refinamiento del backlog. Es la preparación de historias de usuario para la siguiente iteración. Si no se conocen las dependencias entre tareas entonces el product owner puede solicitar al equipo la realización de un “spike“, con el fin de conocer los riesgos. Señala que el equipo no debería de emplear más de una hora a la semana en refinar historias. En caso contrario podría indicar que al equipo le faltan habilidades técnicas necesarias para evaluar y refinar el trabajo.
  • Reuniones diarias. Las mini reuniones diarias (de no más de 15 minutos) se usan para declarar lo trabajado, lo que se va a trabajar, así como para hacer aflorar posibles problemas. No se deben convertir en sesiones de análisis de situación del proyecto ni tampoco se deben usar para tratar de resolver problemas.
  • Demos/reviews. Para proporcionar feedback al product owner, se organizan demos de lo desarrollado en cada iteración. Deben ser frecuentes para así poder dar con la dirección adecuada.
  • Planificación de la iteración. La capacidad de cada equipo es diferente. Se debe hacer una estimación de la capacidad.
  • Prácticas de ejecución que ayudan a los equipos a entregar valor:
    • Integración continua
    • Test en todos los niveles
    • ATDD test de aceptación.
    • TDD y BDD test driven development y behavior driven development
    • Spikes. Útiles para aprender sobre elementos técnicos o funcionales críticos.
  • Cómo las iteraciones y los incrementos ayudan a entregar producto. Las iteraciones ayudan al equipo a crear una cadencia de entrega y muchos tipos de feedback. Las demos son una parte necesaria dentro del flujo de los proyectos ágiles.

Por otra parte, se señalan los desafíos que implican los proyectos ágiles y las posibles soluciones. Muy interesante esta parte.

Medidas en los proyectos ágiles:

  • Es un desafío tratar de determinar la medida de avance en un proyecto ágil. Además de las medidas cuantitativas habituales, cobra importancia añadir medidas cualitativas, como la satisfacción del usuario o la moral del equipo de desarrollo.
  • Los valores de avance en agil son empíricos y tratan de lo que se ha hecho, en lugar de que va a realizar. Por su naturaleza, la estimación se limita a unas pocas semanas.
  • La velocidad del equipo calculada en story points es lo que realmente puede permitir hacer una estimación de cuando se podrá terminar el proyecto.
  • Si el quipo depende de las tareas de externos al proyecto, esto puede interferir en su velocidad notablemente.
  • Para que el progreso de un proyecto ágil sea comprensible a un project no iniciado en ágil, se hace una equivalencia de cómo calcular el Valor Ganado (EMV) haciendo un sencillo cálculo del índice SPI (cronograma) características completadas/características planificadas y del CPI (coste) valor ganado/costes actuales

6 Consideraciones organizativas para proyectos agiles

Los autores son conscientes de que los proyectos existen en un contexto determinado. Por eso se considera fundamental el cambio organizativo que permita aplicar la agilidad, en especial se consideran fundamentales los cambios asociados a la entrega rápida y frecuente y a los cambios constantes en los requerimientos. El mismo PMI publicó una guía para gestionar el cambio en las organizaciones: Managing Change in Organizations: a Practice Guide

Dice la frase de Peter Druker “Culture eats strategy for breakfast”, la cultura de la empresa, que es su ADN, siempre impacta de forma intensa en las estrategias y en especial en el uso de aproximaciones ágiles en la gestión de proyectos.

Respecto a la parte de la gestión de contratos con proveedores, los autores animan a seguir un esquema de contratos de tipo “win-win”, (todos ganan con el acuerdo) que no es una característica en absoluto privativa de los enfoques ágiles.

Por otra parte, los típicos contratos con proveedores que se firman en ciclos de vida predictivos pueden generar grandes riesgos si se trasladan a ciclos de vida ágiles. En especial, puede ser muy arriesgado firmar tanto contratos de tipo “Time and Materials” o “llave en mano” con precio cerrado.

Se menciona cómo gestionar varios equipos ágiles, cuando se requiere la gestión de un portfolio o un programa se hace necesaria. En Scrum se desarrolla el “Scrum of Scrums“.

Es destacable la parte que habla de la relación entre proyectos ágiles y la PMO (Oficina de Gestión de Proyectos). La PMO ayuda a los equipos de proyectos a tener éxito. Y dado que la agilidad crea un cambio, por consiguiente, la PMO debe cambiar y debería perseguir ayudar a los equipos ágiles, una PMO ágil debería de ser una PMO que busque la satisfacción de los usuarios y compatibilizar este objetivo con ser un centro que busque la excelencia.

7 Llamada a la acción

La demanda de agilidad está incrementándose en todos los sectores, la cuestión es cómo enfocar los proyectos para que se aprovechen los beneficios de la agilidad. Y los autores son conscientes de que sus lectores pueden haber echado en falta más información. Precisamente por eso apuntan a seguir cubriendo este interesante tema en sucesivas entregas.

 

 

 

APÉNDICES:

El libro finaliza con una interesante selección de apéndices, entre los cuales destaca el Apéndice X3 Modelo para la Idoneidad del Enfoque Ágil, enfocado a determinar cuándo es mejor utilizar un enfoque ágil en los proyectos

CONCLUSIÓN:

¿Cuál es el objetivo de este libro? Se trata de buscar una aproximación e integración entre las metodologías predictivas y el mundo ágil. ¿Y cómo enfocar esa integración? Está claro que no se trata solamente de añadir más apartados al PMBOK que ya está en su sexta edición. Se trata de construir una versión unificada de ambos puntos de vista. Creo que, aunque se trate de metodologías muy diferentes, el Project manager deberá escoger la más adecuada que dependerá del tipo de proyecto de que se trate. Tan sencillo como que se aproveche lo mejor de cada una de ellas, es decir, la aproximación “híbrida” a la gestión de proyectos. Un Project manager que se precie, debería saber qué enfoque adoptar, en base a las características del proyecto. Una tendencia que se destaca después de una lectura del PMBOK 6 es que las diferentes metodologías empiezan a converger y cada una adopta lo mejor de las otras.

Es un libro hecho para ser leído por Project managers expertos en proyectos predictivos, que deseen conocer lo que les puede aportar el enfoque agile. A un experto en agilidad no le va a aportar nada nuevo.

Esta lectura me ha sabido a poco. Es un tema muy interesante y que tiene mucho recorrido por delante. Esperemos que no tarden en publicar más libros sobre esta temática.

REFERENCIAS:

What is the Purpose of the New PMI Agile Practice Guide?

ACTUALIZACIÓN DE 2018:

Ya ha salido publicada en español la Agile Practice Guide.

Este libro se puede obtener en estos dos sitios:

  • Siendo miembro de PMI:
    • Se puede descargar de forma gratuita en formato pdf (protegido) desde la web de PMI
    • Alternativamente, se puede encargar en formato papel a mitad de precio que los no miembros
  • No siendo miembro de PMI: