¿Qué es un Gestor de Proyectos Ágiles?

Hace unas semanas recibí un mensaje de correo electrónico de un alumno con una noticia decepcionante – su empresa había despedido a todos los ScrumMasters y los había reemplazado con “Gestores de Proyectos Ágiles”. Eso significaba que uno de mis antiguos estudiantes había perdido su trabajo, estaba buscando trabajo y que Scrum había sufrido un grave retroceso en su organización. Eso fue muy triste :(

Cuando leí por primera vez el mensaje, pensé para mí mismo “¿Qué es un” Gestor de Proyectos Ágiles “? Por lo tanto, hice algunas investigaciones para ver cuando surgió este término (a principios del 2008), para buscar algunos artículos sobre estos Gestores de Proyectos Ágiles (APM-por sus siglas en inglés) y para averiguar lo que son y por qué las empresas los prefieren a ellos más que a los ScrumMasters.

1. ¿Qué es la Gestión de Proyectos Ágiles?: Breve descripción de Mike Cohn y su mensaje es bastante consistente con respecto a lo que Scrum piensa sobre la gestión y sobre los Equipos de Scrum.
2. Gestión de Proyectos Ágiles – VersionOne proporciona su definición de un APM y muchos recursos para apoyarlos, lo que no es demasiado sorprendente puesto que VersionOne es un vendedor de herramientas que vende a APM.
3. ¿Por qué el Gestor de Proyectos Ágiles es la Salsa Secreta para Proyectos de Desarrollo?: Este artículo de InfoQ escrito por Leonardo Abdala (@leonardoabdala) describe por qué él siente que los grandes proyectos necesitan un APM y está basado en su experiencia con equipos distribuidos.
4. Los PMP vs Los Gestores de Proyectos Ágiles: Furia de Titanes: Este artículo que se encuentra en el sitio web de la Scrum Alliance está escrito por Juan Banda (@juanbandajara) compara un PMP (como se define por PMI) con un APM.
5. Agilidad y PMI: Finalmente tenemos la perspectiva de Ken Schwaber que es coherente con la forma en que él y Jeff Sutherland han definido y aplicado Scrum durante años.

Cuando la mayoría de las personas piensan en un gestor de proyectos, se imaginan a alguien que es responsable de la gestión del alcance, del costo, de la calidad, del personal, de la comunicación, del riesgo, de las adquisiciones y de otros aspectos de la entrega del producto. Esta es la persona que normalmente culpamos si algo sale mal o la persona que machacamos si sentimos que las cosas de alguna manera van mal.

Personalmente, nunca he entendido por qué alguien aceptaría estas responsabilidades. El gestor de proyectos no es la persona que hace el trabajo, entonces, ¿cómo puede ser responsable de la calidad o del horario? El gestor de proyectos no decide los objetivos del negocio, entonces, ¿cómo puede manejar realmente el alcance? ¿Y debería manejar el alcance si el dominio del negocio está cambiando constante y rápidamente? El gestor de proyectos no es generalmente un gestor funcional, entonces, ¿cómo se le puede considerar responsable del personal o de su desempeño? Entiendo que esta es la forma en que PMI quiere definir el rol de gestor de proyectos, pero yo quiero un poni y eso no significa que vaya a conseguir uno.

Basándome en mi experiencia, suelo pensar que los gestores de proyectos no concuerdan con Scrum. Si lees a Ken Schwaber, él nos dice que deliberadamente se dejó fuera de Scrum a los gestores de proyectos. En su opinión, los gestores de proyectos son contraproducentes para trabajar con conocimientos, reducen la creatividad y disminuyen la inteligencia del Equipo (casi puedo oír a todo el colectivo de las personas que apoyan esta declaración gritando: “¡Hip! ¡Hip! ¡Hurra!” y al colectivo de las personas que no están de acuerdo con Ken diciendo:”¡Vaya burro!”). Si lees la definición de gestor de proyectos para un equipo de software de PMI, lo que dice y, así es en muchos casos, es que se trata de alguien que le dice a la gente cómo hacer su trabajo o de una niñera del proyecto. Estos dos comportamientos son muy irritantes para profesionales altamente cualificados y disminuye el respeto, la confianza, el compromiso, el foco y la autoorganización. Cuando la gente me dice que sus compañías han despedido a los ScrumMasters a favor de los APM, lo que están diciendo es que quieren tener a una persona a la que puedan culpar si algo sale mal.

Seguro que sería bueno poder mirar a un diagrama y ver el nombre de alguien en un recuadro (siempre en la parte superior de la pirámide) y decir “Oh sí…Carlton. Esa es la razón por la que este proyecto falló – es un gestor de proyectos malísimo”. Sería bueno (como tener un poni), pero en muchos casos simplemente no sería cierto. Los esfuerzos para crear un producto fracasan por muchas razones. Muchos de estos fracasos se deben a lo que yo llamo las condiciones iniciales: la forma en que se inició el proyecto (no hay suficiente tiempo o recursos), la falta de acceso a la toma de decisiones de forma autónoma o las limitaciones de la organización, es decir, la burocracia y la aversión al éxito.

En Scrum, contamos con Equipos que hacen el trabajo y que se responsabilizan de la calidad, de la comunicación y de los riesgos técnicos de la autoorganización. El Propietario del Producto es responsable de la comunicación, el alcance, el costo y el riesgo del negocio. Si bien no existe un gestor de proyectos en Scrum, los proyectos o programas que son muy complejos o tienen un montón de gestiones, todavía necesitan que se realicen algunas tareas de gestión del proyecto (fíjate en la distinción que hago). Tales actividades de gestión son la gerencia del personal, las adquisiciones, la comunicación empresarial y otras actividades que normalmente las realiza el gestor del proyecto y que sería mejor que las realizara alguien en el Equipo cuya función principal sea la gestión. Sin embargo, tenga en cuenta que esas personas no están dirigiendo al Equipo, sino las actividades de gestión.

Esta enlace va el artículo original en inglés.