El jefe de proyecto ha muerto

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”. 😉

  • amisai

    Muy buen post :-).

    A mi tampoco me gusta la palabra “jefe de…”, siempre que he tenido este tipo de roles he preferido la palabra coordinador a “director de…” o “jefe de …”, me tira más el concepto de colaboración entre pares y la idea del líder como servidor del resto del equipo.

    Por cuestiones laborales, según iba leyendo el post he encontrado dos ideas que resuenan con mi experiencia reciente: la del mando intermedio que tiene que confiar en su equipo, y la del reparto de responsabilidades. Respecto de la primera, imagino que es porque me ha costado un par de sprints entender a mi nuevo (esto condiciona mucho, claro) equipo y ver lo que cada uno podemos aportar. Y de la segunda, y aún entendiendo que el post se centra en la figura de jefe de proyecto, creo que el cambio de mentalidad debe ser compartido por todos los roles: esos programadores que no arreglan un bug “porque nadie me lo ha dicho” también deberían de extinguirse…

    Y al final, es una cuestión cultural: lo que como empresa/grupo de personas/… hacemos, lo que no, lo que permitimos que los miembros de nuestro grupo hagan (o dejen de hacer) a otros miembros y como hacemos para potenciar a todo el grupo en su conjunto y cada miembro en particular.

    Sigue escribiendo así, nos hace falta 😉

    • Gracias Abel. Ya sabes que tú eres parte importante de la calidad de lo que publico. 🙂

      Respecto a lo que comentas acerca del cambio de rol de los miembros del equipo, es cierto, debería haber hecho más énfasis. Al final, “deberíamos hacernos la pregunta de cómo podemos ayudar a nuestros compañeros “jefes de proyecto” en su travesía” se ha quedado bastante diluida. Creo que hablamos poco de la importancia de los valores del grupo para que Agile funcione. Igual debería dedicar un artículo exclusívamente a esto.

      Muchas gracias de nuevo, Abel.
      Un abrazo,
      JMB

  • David Vaquero

    Buenas noches. Vaciar de responsabilidad el perfil del jefe de proyecto puede tener un par de efectos negativos por parte del propio jefe. Primero al dejarle sin parte de sus funciones, puede entender se como un motivo para que su categoría profesional deje de tener sentido. Por lo que su sueldo puede verse mermado a la hora de renegociar un convenio laboral.
    Si se plantea como una reconversion del perfil se pueden tener más posibilidades de éxito en el cambio de paradigma empresarial. Los mandos intermedios paran muchos conflictos a los ap y p que vienen de arriba, cuando el jefe es bueno claro.

    • Hola David. Gracias por recordar el efecto que puede tener (y de hecho tiene) este reparto de responsabilidades entre el jefe de proyecto tradicional y el resto del equipo en un ambiente ágil.

      Veo frecuentemente que algunos jefes de proyecto viven la situación como una disminución de atribuciones y, por tanto, como una amenaza a su continuidad. Bien, es cierto. Desde una perspectiva Lean, una actividad que no aporta valor debe ser eliminada. Cuando comentas que es útil ese papel mediador, coincido contigo. Aunque me atrevo a retarte para que te plantees un posible escenario donde cualquier miembro del equipo tenga las mismas habilidades e información necesarias para abordar esos conflictos sin necesidad de intermediarios.

      Por otro lado, también veo frecuentemente que el resto de roles, tradicionalmente en esa incómoda zona de confort que proporciona el jefe de proyecto, se sienten sobrecargados por las nuevas responsabilidades. Yo suelo explicar que, en realidad, estas responsabilidades siempre habían sido suyas pero que es hora de ejercerlas por los motivos que explico arriba en el artículo.

      El final de mi artículo pretendía ser una llamada a todos para ayudar a los jefes de proyecto tradicionales a adaptar su rol al trabajo en un contexto Agile, donde también los empresarios (o los consultores que ayudan en las reorganizaciones) tienen/tenemos que ayudar a hacer encajar las piezas.

      Gracias por tu aportación, David.

      • David Vaquero

        Challenge accepted!
        Con un grupo de trabajo con puestos rotatorios asíncrono. Es decir, al mismo tiempo un jefe de proyecto es ap y viceversa.
        Transparencia de las informaciones del proyecto del presupuesto a la entrega.
        Un saludo

      • Hola David. Qué bueno que pensaste en ello. Sin embargo no sé si entiendo bien el escenario que comentas. ¿Se trata de un equipo donde todos son desarrolladores y, además, hay un turno rotatorio para encargarse de las labores de coordinación, reporte, etc del proyecto? Si es así, estaría genial conocer cuáles son los beneficios e inconvenientes de esta rotación. (Desde todos los puntos de vista, incluido el de los clientes)
        Gracias de nuevo

      • David Vaquero

        Partimos de un jefe de proyecto tradicional con un equipo de programadores a su cargo. Se escoge a un AP o P para que coja la gestión del siguiente proyecto, bajo el jefe de proyecto actual, que hace de mentor al nuevo “Jefe de proyecto”. Se empieza por proyectos pequeños para ir adaptando el aprendizaje del nuevo jefe. Si terminas por incorporar a todos los miembros del equipo a este nuevo rol. Ya no sería necesaria esa parte de la jerarquía. Incluso el propio equipo podría elegir quien se encargará del siguiente proyecto por los motivos que consideren oportunos. De ahí lo de puesto rotatorio, como un ejemplo. Y asíncrono porque uno es a la vez jefe y programador, todo depende del proyecto.
        Beneficios: es una especie de Roleplaying, en el que el P es consciente de las tareas del Jefe. Aprende a valorar el trabajo del Jefe y le vas preparando para su ascenso en la empresa. Mejora la compresión entre roles. El equipo funcionando es mucho más flexible en su composición ya que muchos conocen las labores del resto de roles. Se reducen las fricciones por la jerarquía. Para el cliente, no hay mucho cambio. Siempre tiene alguien a quien preguntar, de la misma manera que el modelo anterior. Team building por las dinámicas de roleplaying. Los miembros del equipo se ven más involucrados en el proyecto.
        Riesgos: Fallos en el inicio del cambio de modelo debido al proceso natural de aprendizaje. Gestión de la resistencia al cambio.

      • Qué buena experiencia, David. ¿Cuánto tiempo hace que la estáis poniendo en práctica?

  • Pingback: Entornos multiculturales y creencias – Se hace camino al andar…()

  • Benja Garrido

    Me quedo como resumen con “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”

    Genial post!

    • Gracias Benja. Sí, es un buen resumen de lo que quería transmitir con el artículo.

  • Pingback: CAS2017 – Se hace camino al andar…()