Últimamente leo artículos de la comunidad ágil atacando la figura del project manager y la disciplina del project management. Me llega el mensaje de que los project managers ya no somos necesarios en los proyectos software. Se dice que estamos en en el lado oscuro. Impedimos el buen desempeño del equipo, el trabajo de buena calidad, la orientación al valor, el ritmo sostenible, el espíritu de equipo, la creatividad, el sentido común, etc.

Es verdad que muchas veces se observa todo esto en los proyectos software, pero ¿seguro que siempre es culpa del project manager? Y cuando lo es, ¿seguro que ese project manager está dirigiendo correctamente el proyecto ágil?

Estas lecturas me impactan profundamente porque yo me considero, como muchos otros colegas, parte activa de la comunidad ágil, y de verdad que no sentimos que estemos en el lado oscuro cuando nos toca dirigir un proyecto ágil. Cuando hablan de suprimir nuestro rol, nos preguntamos: Entonces ¿quién se va a responsabilizar de terminar el proyecto en plazo y dentro del coste aprobado? Y seguramente nuestros jefes se preguntarán: Entonces ¿a quién le vamos a echar la culpa cuando el proyecto salga mal? ;-D

Demonizar la figura del project manager, o la práctica de la gestión de proyectos, es una simplificación injusta y desacertada. El estado actual y las tendencias del project management van justo en el sentido contrario:

  • Los marcos y métodos de gestión de proyectos reconocen que hay dos tipos mayoritarios de ciclos de vida de desarrollo de proyectos: 1) Ciclo de Vida Predictivo (= en cascada) y 2) Ciclo de Vida Adaptativo (= ágil= orientado al valor= orientado a los cambios).
  • Los organismos de certificación en gestión de proyectos más reconocidos están incorporando titulaciones específicas para gestionar proyectos ágiles y han modificado las titulaciones generalistas para que los aspirantes tengan una base de gestión de proyectos ágiles.
  • La mayoría de las organizaciones públicas y privadas están adaptando sus métodos y modelos de gestión, reconociendo que en sus portafolios hay proyectos predictivos y adaptativos, y aplican modelos ágiles no solo para los proyectos software, sino también para los proyectos de negocio en fases creativas o experimentales, o cuando simplemente los requisitos no están claros.

Los marcos ágiles no mencionan el rol del project manager porque se diseñaron para la gestión de productos, no de proyectos. No obstante, el rol PM es requerido siempre que la organización aprueba un proyecto que debe terminar dentro un plazo determinado y por debajo de un presupuesto. El PM profesional se responsabiliza, entre otras cosas, de que el proyecto ágil termine a tiempo y sin exceder el presupuesto, tratando de satisfacer los requisitos del grupo de interesados.

El project manager de hoy día no es un profesional completo si no sabe cómo se gestionan los dos tipos de proyectos:

En un proyecto predictivo se cierran la mayor parte de los requisitos al principio y después se avanza por fases sencuenciales. Son ejemplos típicos los proyectos de ingeniería y construcción, denominados a veces EPC: Engineering, Procurement and Construction. El rol del project manager en estos proyectos consiste en cerrar un plan para la dirección del proyecto –que incluye un diagrama Gantt y otros muchos componentes que podrán modificarse si es necesario– para utilizarlo a modo de “partitura” para dirigir a los miembros del equipo como si fueran los músicos. En las reuniones de seguimiento, se compara el desempeño real con el planificado y se toman acciones correctoras para acercarnos a las líneas base. De esta manera, midiendo y ajustando sucesivamente, logramos cumplir el plazo, el coste, etc.

Si estamos hablando de un proyecto software en cascada, el flujo es mayoritariamente unidireccional, como en una “cascada”: Se cierran todos los requisitos técnicos, después se desarrolla y se cierra todo el modelo funcional, después se diseña y se aprueba toda la arquitectura, después se acomete la fase de desarrollo, y finalmente la fase de pruebas y el pase a producción.

Cuando se sabe claramente casi todo lo que hay que hacer, es muy eficiente trabajar por lotes: primero todos los requisitos, luego toda la especificación funcional, etc. Ya que nos ponemos a desarrollar el sistema de información en español, hagámoslo también en inglés… Igual que el agua no vuelve hacia arriba en una cascada, una vez se avanza a la siguiente fase, ya no se vuelve a la anterior. Como todo el mundo sabe, este modelo en cascada generalmente no funciona para informática de gestión ni para desarrollos web, pero sigue usándose para desarrollar software de misión crítica –por ejemplo en el sector aeronáutico–, software embebido –sirva como ejemplo el software que puede haber en un coche autónomo–, o bien en productos software con un componente muy alto de requisitos no funcionales, o con un roadmap muy predeterminado, etc.

¿Por qué no sirve el modelo en cascada para la mayoría de proyectos software, dirigidos a usuarios finales que deben utilizarlos para realizar determinadas operativas? Sencillamente, porque es muy difícil, si no imposible, cerrar apropiadamente los requisitos del sistema de información. Si trabajamos en cascada y entregamos por primera vez después de 5 meses, lo más probable es que se rechace mucha funcionalidad y haya que asumir mucho retrabajo.

Yo mismo, que siempre he criticado a los clientes porque no se ponían de acuerdo y me parecía que me querían cambiar los requisitos caprichosamente, ahora que estoy en el lado cliente, desarrollando PMPeople, un software con mucha funcionalidad y para eso estamos subcontratando a una software factory en India, ahora soy yo quien debe de parecer caprichoso porque quiero cambiar los requisitos continuamente. A pesar de que yo me considero experto a la hora de modelar sistemas de información, cuando empezamos el proyecto, yo era incapaz de cerrar los requisitos. Este software era demasiado grande para planearlo suficientemente. Ahora que ya estamos dando servicio a clientes, comparo los mockups de hace 3 años con las pantallas que usan los clientes ahora y no tienen nada que ver.

El gran drama de los proyectos software, con el que tenemos que convivir, es que el cliente de un proyecto software no sabe lo que quiere, solo sabe lo que no quiere.

“El cliente de un proyecto software no sabe lo que quiere, solo sabe lo que no quiere.”

Por eso es tan rentable descubrir el valor, practicando iteraciones frecuentes que terminan demostrando algo funcionando, típicamente cada 2 semanas. Cuando los indios nos hacen una demo, es entonces cuando yo tengo clarísimo lo que quiero. Si hubiéramos elegido un método predictivo para gestionar este proyecto, el proyecto habría fracasado y lo tendríamos que haber cancelado hace tiempo. La mejor decisión de este proyecto fue elegir un ciclo de vida orientado al valor:

¿Como gestioné este proyecto ágil? Al principio limité plazo entre 12-18 meses. El objetivo era tener una versión beta lista para implantar en clientes (B2B). Más allá de esa fecha de fin, al gestionar el trabajo de mantenimiento correctivo, aunque técnicamente era parecido, ya no gestionaba un proyecto, sino un producto. Cuando nos planteamos el lanzamiento de la versión móvil, esto fue otro proyecto, y fue muy beneficioso contar con el mismo equipo de la software factory, al menos con el mismo product owner. El lanzamiento del modelo freemium para el público general (B2C SaaS) fue otro proyecto.

Con ese plazo predeterminado para realizar un trabajo que visualizábamos en líneas generales con los requisitos de alto nivel, y con un tamaño de equipo más o menos estable que nos ofrecían, pude calcular fácilmente una primera estimación del presupuesto. En terminología Scrum, yo me consideraba “chicken” (junto con otros colegas que confirmaban el valor). En el proyecto yo asumí los roles de business analyst y project manager. Hablaba muy a menudo con el Product Owner y detrás había un equipo técnico y el Scrum Master.

Usamos Asana para gestionar las listas y los tableros y Slack para la comunicación continua. Comparto el product backlog con el product owner, no veo los sprint backlogs ni atiendo ya a los daily standups (es muy pronto aquí en España). Tenemos visibilidad sobre el tamaño en horas ideales de cada historia. Practican integración continua: Cuando terminan una historia, la despliegan al entorno de pruebas y mueven la tarjeta del tablero de “in progress” a la columna “testing”. Me llega la notificación de Asana y ya sé que tengo pendiente hacer las pruebas. Si las pruebas se superan, marco la historia como terminada y la muevo a la columna “done”. En caso contrario, la devuelvo a “in progress”:

Diariamente, el Scrum Master actualiza la gráfica de quemado en Excel (para descargar la plantilla, pulsar aquí).

Para controlar un proyecto ágil no suele servir de mucho hacer un Gantt. Veríamos tareas resumen con las releases una detrás de otra, pero el proyecto generalmente va en fecha, siendo las únicas desviaciones ocasionadas por algún que otro spike de vez en cuando.

En nuestro caso, al principio planteamos 5 releases:

  • En la primera release, el resultado fue el prototipo PDF dinámico de la aplicación móvil: unos 100 mockups en Balsamiq que pudimos mostrar a muchos colegas para validar y corregir muchos enfoques sin contratar todavía a la software factory. Puede descargar el fichero PDF aquí. Si abre el fichero descargado, podrá navegar siguiendo los enlaces del pdf, como se muestra en este vídeo.
  • En la release 2, la orientación al valor consistió en el desarrollo iOS y Android de la primera versión de la aplicación móvil. No es funcional pero sí permite navegar y mostrar la funcionalidad de alto nivel.
  • En la release 3 desarrollamos la primera versión de la aplicación web, que permitía usar todos los roles salvo el Resource Manager y usar la estructura de proyectos, programas y portafolios.
  • En la release 4, se implementó la funcionalidad básica para proyectos y recursos: el rol de resource manager, gestión de pools, flujo de aprobación de horas y gastos, etc.
  • En la release 5, implantamos lo que faltaba para liberar la versión comercial: entorno multi-organización, invitación entre usuarios, seguimiento de proyectos, EVM, Gantt, gestión de tareas y paquetes de trabajo.

En esta experiencia de gestión de un proyecto ágil, me parece que las labores que estoy realizando día a día encajan bastante bien con el rol de agile practitioner delineado por PMI®. En el texto que usa PMI® para especificar el examen PMI-ACP® se describen 7 dominios que resumen las principales áreas de responsabilidad del Director de Proyectos Ágil.

1. Principios Ágiles: Explorar, fomentar y aplicar principios ágiles en el contexto del equipo del proyecto y la organización.

2. Entregar conforme al valor: Entregar resultados de valor produciendo entregas incrementales de alto valor revisables, pronto y a menudo, basándose en las prioridades de los interesados. Hacer que los interesados proporcionen retroalimentación a partir de estas entregas, con el fin de priorizar y mejorar las entregas incrementales futuras.

3. Involucrar a los interesados: Gestionar la involucración de los interesados actuales y futuros generando un entorno de confianza que permita alinear sus necesidades y expectativas y equilibrar sus peticiones haciendo que comprendan el coste/esfuerzo que suponen. Promover la participación y la colaboración a lo largo del ciclo de vida del proyecto y proporcionar las herramientas para la toma de decisiones eficaces e informadas.

4. Desempeño del equipo: Crear un entorno de confianza, aprendizaje, colaboración y resolución de conflictos que fomente la auto-organización del equipo, mejore las relaciones entre los miembros del equipo y cultive una cultura de alto rendimiento.

5. Planificar de forma adaptativa: Producir y mantener un plan que evolucione desde el inicio hasta el cierre, basado en objetivos, valor, riesgos, restricciones, retroalimentación de interesados y revisión de los hallazgos.

6. Detectar y solucionar problemas: Identificar continuamente problemas, impedimentos y riesgos. Priorizarlos y resolverlos de manera oportuna. Monitorizar y comunicar el estado de resolución de los problemas e implementar las mejoras de procesos que eviten que vuelvan a ocurrir.

7. Mejorar continuamente (Producto, Proceso, Personas): Mejorar continuamente la calidad, efectividad y el valor del producto, del proceso y del equipo.

¿A alguien le parece que un project manager que es responsable de todo esto de verdad estorba al equipo ágil?

Si quedan todavía dudas, profundicemos un poco más. En cada uno de estos dominios de práctica, los project managers realizan una serie de actividades. Veamos la lista de tareas que según el PMI® debería practicar en su día a día el project manager ágil:

En el dominio 1. Principios Ágiles:

  1. Fomentar los principios ágiles modelándolos y discutiendo los valores ágiles para desarrollar un entendimiento común dentro del equipo y entre el equipo y los interesados.
  2. Ayudar a asegurar que todos tengan un entendimiento común de los valores y principios ágiles, de las prácticas ágiles y la terminología empleada para trabajar de manera efectiva.
  3. Apoyar el cambio en la organización educando e influenciando sobre los procesos, comportamientos y personas para hacer la organización más eficaz y eficiente.
  4. Practicar la visualización por medio de radiadores de información muy visibles que muestren el progreso y desempeño real del equipo para fomentar la transparencia y la confianza.
  5. Fomentar un entorno de seguridad y confianza, permitiendo que todos experimenten y cometan errores para que puedan aprender y mejorar continuamente la forma de trabajar.
  6. Mejorar la creatividad experimentando con nuevas técnicas e ideas sobre los procesos, para descubrir formas de trabajar más eficientes y eficaces.
  7. Fomentar que los miembros del equipo compartan el conocimiento colaborando y trabajando juntos para reducir los riesgos de islas de conocimiento y cuellos de botella.
  8. Estimular el liderazgo emergente dentro del equipo estableciendo un entorno respetuoso y seguro en el que puedan probarse nuevos enfoques para producir mejoras y fomentar la auto-organización y el facultamiento.
  9. Practicar el liderazgo servicial ayudando y estimulando a otros en sus esfuerzos, de manera que puedan trabajar a su máximo nivel y continuar mejorando.

En el dominio 2. Entregar conforme al Valor:

2.1. Definir Valor Positivo:

  1. Definir entregables identificando unidades que puedan producirse incrementalmente para maximizar su valor para los interesados minimizando las actividades que no aporten valor.
  2. Refinar los requisitos lo más tarde posible consensuando los criterios de aceptación de las funcionalidades para entregar valor.
  3. Seleccionar y adaptar los procesos del equipo basándose en las características del proyecto y de la organización así como la experiencia del equipo para optimizar la entrega del valor.

2.2. Evitar Inconvenientes Potenciales:

  1. Planificar entregas incrementales pequeñas organizando los requisitos en funcionalidades mínimas vendibles o productos mínimos viables, para facilitar anticipadamente el reconocimiento y la entrega de valor.
  2. Limitar el tamaño de los incrementos y mejorar la frecuencia de las revisiones con los interesados apropiados para identificar y responder a los riesgos pronto y al mínimo coste.
  3. Solicitar retroalimentación a clientes y usuarios mediante la demostración frecuente de los incrementos para confirmar y mejorar el valor para el negocio.

2.3. Priorización:

  1. Priorizar las unidades de trabajo a través de la colaboración con los interesados para optimizar el valor de los entregables.
  2. Realizar revisiones y mantenimientos frecuentes de los resultados del trabajo priorizando y manteniendo internamente la calidad para reducir el coste total del desarrollo incremental.
  3. Identificar y priorizar continuamente los factores ambientales, operacionales y de infraestructura para mejorar la calidad y el valor de los entregables.

2.4. Desarrollo Incremental:

  1. Realizar revisiones operativas y/o puntos de control periódicos con los interesados para obtener retroalimentación y correcciones al trabajo en curso y planificado.
  2. Equilibrar el desarrollo de unidades entregables y esfuerzos de reducción de riesgos incorporando tanto trabajos para producir valor como para reducir riesgos en la pila, para maximizar la propuesta de valor total a lo largo del tiempo.
  3. Re-priorizar periódicamente los requisitos para reflejar cambios en el entorno y necesidades o preferencias de los interesados para maximizar el valor.
  4. Recopilar y priorizar requisitos relevantes no funcionales (como de operación y seguridad) considerando el entorno en que la solución será usada para minimizar la probabilidad de fallo.
  5. Realizar revisiones frecuentes de los productos del trabajo con inspecciones, revisiones, y/o pruebas para identificar e incorporar mejoras en el proceso completo y el producto/servicio.

En el dominio 3. Involucrar a los Interesados:

3.1. Comprender las Necesidades de los Interesados:

  1. Identificar e involucrar a los interesados efectivos y facultados a través de revisiones periódicas para asegurar que el equipo es conocedor de los intereses, necesidades y expectativas de los interesados.
  2. Identificar e involucrar a los interesados (actuales y futuros) promoviendo la compartición del conocimiento desde el principio y durante todo el proyecto para asegurar un flujo sin obstáculos de la información y el valor durante toda la vida del proyecto.

3.2. Asegurar la Involucración de los Interesados

  1. Establecer relaciones con los interesados construyendo acuerdos de trabajo entre los interesados clave para promover la participación y la colaboración efectiva.
  2. Mantener la involucración adecuada de los interesados continuamente evaluando los cambios en el proyecto y la organización para asegurar que los interesados se involucran apropiadamente.
  3. Establecer comportamientos colaborativos entre los miembros de la organización fomentando la toma de decisiones y la resolución de conflictos en grupo para mejorar la calidad de las decisiones y reducir el tiempo requerido para decidir.

3.3. Gestionar las Expectativas de los Interesados:

  1. Establecer una visión común de los diversos incrementos del proyecto (productos, entregables, releases, iteraciones) desarrollando una visión de alto nivel y apoyando los objetivos para alinear las expectativas de los interesados y generar confianza.
  2. Establecer y mantener un conocimiento compartido de los criterios de éxito, entregables y acuerdos aceptables facilitando la concienciación entre los interesados para alinear expectativas y generar confianza.
  3. Proporcionar transparencia en relación al estado del trabajo comunicando el progreso del equipo, la calidad del trabajo, los impedimentos y los riesgos, para ayudar a los principales interesados a tomar decisiones informadas.
  4. Proporcionar pronósticos detallados compensando la necesidad de certidumbre y los beneficios de la adaptabilidad, de tal forma que los interesados puedan planificar de manera efectiva.

En el dominio 4. Desempeño del Equipo:

4.1. Desarrollo del Equipo:

  1. Cooperar con los otros miembros del equipo para idear reglas básicas y procesos internos para fomentar la coherencia del equipo y fortalecer el compromiso de los miembros del equipo con los resultados compartidos.
  2. Ayudar a crear un equipo que tenga las habilidades interpersonales y técnicas necesarias para conseguir todos los objetivos conocidos del proyecto para crear valor para el negocio con el mínimo retraso.

4.2. Facultamiento del Equipo:

  1. Animar a los miembros del equipo a convertirse en especialistas generalistas para reducir el tamaño del equipo y los cuellos de botella,
  2. Contribuir a la auto-organización del trabajo facultando a otros y fomentando el liderazgo emergente para generar soluciones efectivas y gestionar la complejidad.
  3. Descubrir continuamente los factores de motivación y desmotivación del equipo y personales y asegurar que la moral del equipo esté alta y los miembros del equipo permanezcan motivados y productivos a lo largo del proyecto.

4.3. Colaboración y Compromiso del Equipo:

  1. Facilitar la estrecha comunicación dentro del equipo y con los interesados externos apropiados mediante la coubicación o el uso de herramientas de colaboración para reducir la mala comunicación y el retrabajo.
  2. Reducir distracciones para establecer resultados predecibles y optimizar el valor entregado.
  3. Participar en la alineación de los objetivos del proyecto y del equipo compartiendo una visión del proyecto para asegurar que el equipo comprende cómo encajan sus objetivos en los objetivos del proyecto.
  4. Animar al equipo a medir su velocidad monitorizando y midiendo el desempeño real en iteraciones previas o releases para que los miembros ganen una mejor comprensión de su capacidad y creen pronósticos más precisos.

En el dominio 5. Planificar de forma Adaptativa:

5.1. Niveles de Planificación:

  1. Planificar a múltiples niveles (estratégico, release, iteración, día) creando un detalle apropiado usando planificación gradual y elaboración progresiva para equilibrar la predictibilidad de los resultados con la capacidad de explotar oportunidades.
  2. Hacer que las actividades de planificación sean visibles y transparentes fomentando la participación de los interesados clave y publicando los resultados para mejorar el nivel de compromiso y reducir la incertidumbre.
  3. A medida que se desenvuelve el proyecto, situar y gestionar las expectativas de los interesados estableciendo progresivamente niveles específicos de compromiso para asegurar un entendimiento común de los entregables esperados.

5.2. Adaptación:

  1. Adaptar la cadencia y el proceso de planificación a partir de los resultados de las retrospectivas periódicas sobre las características y/o el tamaño/complejidad/criticidad de los entregables del proyecto para maximizar el valor.
  2. Inspeccionar y adaptar el plan del proyecto para reflejar los cambios en los requisitos, cronograma, presupuesto, y mover prioridades teniendo en cuenta el aprendizaje del equipo, la experiencia en las entregas, la retroalimentación de los interesados y los defectos, para maximizar el valor de negocio entregado.

5.3. Determinación del Tamaño y Estimación Ágil:

  1. Poner tamaño a los elementos usando técnicas de elaboración progresiva para determinar el tamaño probable del proyecto independientemente de la velocidad y de variables externas.
  2. Ajustar la capacidad incorporando demandas de operación y mantenimiento y otros factores para crear un rango de estimación actualizado.
  3. Crear un rango de estimación para el alcance inicial, el cronograma y el coste que reflejen el nivel actual de conocimiento de alto nivel del esfuerzo necesario para entregar el proyecto, para desarrollar un punto inicial para gestionar el proyecto.
  4. Refinar los rangos de estimación de alcance, cronograma y costes que reflejen el conocimiento último del esfuerzo necesario para entregar y gestionar el proyecto.
  5. Usar continuamente datos de los cambios en la capacidad de recursos, tamaño de proyectos, y métricas de velocidad para evaluar la estimación hasta la conclusión.

En el dominio 6. Detectar y Solucionar Problemas:

  1. Crear un entorno abierto y seguro estimulando la conversación y la experimentación, para que afloren problemas e impedimentos que frenan al equipo o impiden su capacidad de entregar valor.
  2. Identificar amenazas y problemas educando e involucrando al equipo en varios puntos del proyecto para que los resuelvan oportunamente y mejoren los procesos que causan los problemas.
  3. Asegurar que los problemas se resuelven por los miembros del equipo adecuados y/o se resitúan las expectativas a la luz de los problemas que no pueden resolverse para maximizar el valor entregado.
  4. Mantener una lista de amenazas y problemas visible, monitorizada y priorizada para elevar la responsabilidad, promover la actuación y monitorizar quién es dueño y el estado de resolución.
  5. Comunicar el estado de las amenazas y los problemas manteniendo una lista de amenazas e incorporando actividades en la pila de trabajo para proporcionar transparencia.

En el dominio 7. Mejorar Continuamente (Producto, Proceso, Personas):

  1. Adaptar el proceso revisando e integrando periódicamente las prácticas del equipo, la cultura de la organización, y los objetivos de entrega para asegurar la efectividad del equipo dentro de las guías y normas de la organización establecidas.
  2. Mejorar los procesos del equipo realizando retrospectivas frecuentes y experimentos de mejora para mejorar continuamente la efectividad del equipo, del proyecto y de la organización.
  3. Buscar retroalimentación del producto a partir de entregas incrementales y demostraciones frecuentes para mejorar el valor del producto.
  4. Crear un entorno de aprendizaje continuo proporcionando oportunidades a las personas de desarrollar sus habilidades para desarrollar un equipo más productivo de especialistas generalistas.
  5. Cuestionar los elementos de proceso existentes realizando un análisis del flujo del valor y eliminando desperdicios para mejorar la eficiencia individual y la efectividad del equipo.
  6. Crear mejoras del sistema a partir de la difusión del conocimiento y las prácticas a través de los proyectos y los límites organizativos para evitar que se repitan problemas identificados y mejorar la efectividad de la organización como un todo.