Hace años que uso esta frase para comenzar mi explicación sobre el cambio social que representa la introducción del agilismo en una organización. Lógicamente se trata de una metáfora porque, cuando adoptamos métodos ágiles, nadie mata a nadie (al menos no literalmente). Hablar sobre “la muerte del jefe de proyecto” me permite introducir conversaciones sobre roles, responsabilidades y, sobre todo, acerca de cómo adaptarse al cambio de paradigma respecto de cómo ejercemos el poder en una organización.
Roles y posiciones
Cuando hablamos de Agile es inevitable hablar de un cierto estereotipo del jefe de proyecto, especialmente si usamos el término español “jefe de proyecto”, que enfatiza la posición jerárquica de superioridad, frente al “project manager”, que parece poner foco en la gestión del proyecto. Por ello voy a comenzar dando la palabra a Kent Beck cuando habla de los roles en un equipo de XP en su magnífico “eXtreme Programming Explained”:
Los roles en un equipo XP maduro no son fijos ni rígidos. El objetivo es que todo el mundo contribuya con lo mejor que tenga para ofrecer al éxito del equipo. Al principio, tener roles fijos puede ayudar a aprender nuevos hábitos, como tener gente técnica tomando decisiones técnicas y gente de negocio tomando decisiones de negocio. Una vez que las nuevas (y mutuamente respetuosas) relaciones están establecidas entre los miembros del equipo, los roles fijos interfieren con el objetivo de que todo el mundo haga lo mejor que pueda. Los programadores pueden escribir una historia [de usuario] si es que ellos están en la mejor situación para escribirla. Los jefes de proyecto pueden sugerir mejoras en la arquitectura si es que están en la mejor situación para ello.
Es decir, los roles y las posiciones en un organigrama no son una misma cosa. Cada cuál puede aportar a la solución de los problemas. Beck abunda en esto:
Un programador puede ser un poco arquitecto. Un usuario puede convertirse en un product manager. Un redactor técnico también puede probar. El objetivo no es que la gente cubra roles abstractos, sino que cada miembro del equipo contribuya todo lo que tiene al equipo.
Lo mismo pasa con los jefes de proyecto y la actividad de planificar, que en las metodologías ágiles, por cierto, no es una fase sino una actividad que se realiza continuamente.
Los jefes de proyecto son responsables de mantener los planes sincronizados con la realidad. Normalmente están en la mejor posición para dirigir la mejora del proceso de planificación en sí mismo. Los jefes de proyecto facilitan la comunicación entre equipo y clientes, espónsors, proveedores y usuarios. También facilitan la comunicación interna del equipo, aumentando la cohesión y la seguridad. El poder que ganan por ser un facilitador eficaz supera al que proviene de controlar información importante.
No son los roles
Sin embargo, en el Manifiesto Ágil no se menciona nada sobre nuevos roles, más allá del cliente, la gente de negocio (business people) y los desarrolladores. Es Scrum quien define Dueño de Producto o ScrumMaster y separa las responsabilidades de cuidar el producto o de proteger al equipo de interrupciones. La aparición de nuevas recetas para ser aplicadas en entornos corporativos (pienso en SAFe o ESP) también nos trae nuevos roles. Nada nuevo bajo el sol. Yo diría que es algo inevitable cuando se trata de encajar Agile en una gran organización y reducir al mínimo la fricción con lo que ya existe.
Sin embargo, todas estas fórmulas para la adopción de Agile son un conjunto de principios y prácticas más o menos concretas que se pueden aplicar desde un conjunto de valores u otro. En mi opinión, éso es justamente lo que marca la principal diferencia. No es tanto la pericia o experiencia de los consultores que hayas contratado sino sus valores y los de la organización en los que se trata de implantar el cambio. Los roles que elijas no son más que una práctica más. Por tanto, una implantación de métodos ágiles no se puede quedar simplemente en un cambio de roles y procesos, sino en algo mucho más profundo.
Respeto y reparto del poder
Si vuelves a leer la cita anterior de Kent Beck y echas un vistazo a los principios del Manifiesto Ágil, estoy seguro de que coincidiremos en que el agilismo se basa fuertemente en los valores de colaboración y respeto mutuo. Ahora bien, cuando seguimos, sin más, las órdenes de la jerarquía impuesta, no estamos respetando al resto del grupo, pues todos ellos tienen algo que aportar, cada cuál desde su diversidad profesional y personal. De ahí que definir unos roles estrictos bajo el pretexto de la eficacia en la aplicación de los procesos nos chirríe tanto a algunos.
Existe un razonamiento detrás de esto. No se trata de algo meramente ideológico. Pretender que, siguiendo las órdenes de un mando, resolveremos los problemas de la manera más eficaz y eficiente es no entender la naturaleza del trabajo del conocimiento. Los equipos multidisciplinares tienen éxito no sólo porque estén disponibles todas las habilidades necesarias para resolver problemas complejos, sino porque se les da la oportunidad de entender el problema y ofrecer la mejor de las soluciones posibles. Y además debemos tener en cuenta innumerables aspectos psicológicos, que podemos resumir (en una sobresimplificación) como “motivación”.
Por tanto, el rol de un jefe de proyecto pasa necesariamente de controlador a facilitador, lo que implica un reparto del poder y el cultivo de relaciones de confianza y de valores compartidos por todo el grupo. Sí, el “jefe de proyecto”, como tantos otros al adoptar métodos ágiles, debe salir de su zona de confort y adquirir (o recuperar) habilidades que le permitan ejercer este nuevo rol.
Pero recuerda que no sólo tenemos que pensar en el rol de un “jefe de proyecto ágil” como el de una única persona. También podemos verlo (y de hecho a mí me gusta explicarlo así) como el de un conjunto de responsabilidades que se reparte en el grupo; mediante acuerdos de trabajo explícitos, por supuesto. Por ejemplo, mover el post-it que representa una tarea en un tablero es el ejercicio de este rol de jefe de proyecto pues estamos visualizando y ayudando al grupo a gestionar el trabajo en curso. Lo sé, parece un ejemplo muy simple, y de hecho lo es, pero es muy poderoso hacer énfasis de vez en cuando sobre este cambio de paradigma en la relación de todos los miembros del equipo respecto del poder y las responsabilidades que existían antes de adoptar la metodología ágil de turno. Como miembro de un equipo ágil adquieres una parte de las responsabilidades del “jefe de proyecto muerto” y esto lo cambia todo.
Si te interesa, te recomiendo que leas este otro artículo donde reflexiono sobre este asunto desde la perspectiva del liderazgo.
Pérdida de control
En mi experiencia, la mayor resistencia al agilismo es el miedo a la pérdida de control, que está directamente conectada con cómo se entiende el poder en la organización de turno.
Lógicamente, todo mando intermedio en una transformación de este tipo se siente tremendamente incómodo.
— ¿Me dices que debo confiar en el criterio de esta gente aunque yo sé perfectamente cuál es la mejor decisión y existen muchísimas posibilidades de que se equivoquen al decidir?
— Efectivamente. Debes confiar en ellos.
El mando intermedio es uno de los eslabones más débiles de la cadena pues se encuentra entre dos conjuntos de valores en conflicto: por una lado la jerarquía que le exige promesas y el cumplimiento de las mismas, y por otro lado una organización emergente que le exige capacidad de autoorganización y espacio para aprender, es decir, para equivocarse. Por tanto, los mandos intermedios, también conocidos como “jefes de proyecto” en sus diversas variedades, son los verdaderos héroes de las adopciones ágiles pues se debaten en el permanente conflicto de compartir el poder de las decisiones y la responsabilidad de rendir cuentas a la jerarquía a la que aún están sometidos.
Pero si nos creemos éso de que el agilismo se basa en la colaboración y el respeto mutuo, entonces deberíamos hacernos la pregunta de cómo podemos ayudar a nuestros compañeros “jefes de proyecto” en su travesía. Como Agile coach les trato de ayudar para entender sus posibilidades a la hora de hacer evolucionar su actual rol hacia otro compatible con las nuevas necesidades que se les reclama desde el lado ágil, pero también les ayudo a entender cómo ir cambiando su propio entorno, por ejemplo, construyendo juntos nuevos argumentos que les resuelvan sus conflictos con el resto de la organización que aún no ha cambiado. En la mayoría de las ocasiones, este proceso no es tan fácil como dar respuestas a problemas conocidos, sino que se trata de un trabajo colaborativo y de transformación personal, pues no todo “jefe de proyecto” está dispuesto a morir. En esos casos, mi trabajo es hacerle entender que no se trata de una muerte sino de una evolución. Pero si empiezo con la frase “el jefe de proyecto ha evolucionado” resultaría poco irritante. 🙂
¿Y tú? ¿Cómo ayudas a morir dignamente al jefe de proyecto? Una pista: el capítulo 10 de “eXtreme Programming Explained”. 😉