Roles vs jerarquía

La semana pasada, Vanesa Tejada publicaba un artículo sobre la importancia de la comunicación en el rol del Product Owner en Scrum, muy en la linea de mi serie sobre las conversaciones en el desarrollo de software. Este artículo me inspiró un tweet en el que me quejaba de esta confusión entre el rol del Product Owner y la persona que, en la inmensa mayoría de organizaciones, recibe el título de Product Owner. Hoy quiero escribir sobre cómo veo yo esto de los roles y las posiciones en una organización ágil.

Hace mucho tiempo que empleo frases como “el jefe de proyecto ha muerto” porque creo que una de las grandes carencias de las adopciones de metodologías ágiles (especialmente Scrum, que es la más popular), es que se incorporan buscando equivalencias entre los roles prescritos en la metodología y el organigrama actual de la organización. Así, es frecuente encontrar jefes de proyecto que se convierten “automáticamente” en dueños de producto, aunque desconozcan el producto. O jefes de proyecto que “promocionan” a ScrumMaster porque han recibido un curso que certifica su cualificación como tal, independientemente de si están dispuestos a facilitar que el equipo haga el mejor Scrum posible o no.

No digo que esto se haga de mala fe, pues es natural que todos intentemos encontrar nuestro lugar en un nuevo orden. Sin embargo, creo que debemos ser un poco más rigurosos y propongo una reflexión al respecto de cómo implementamos los roles en una organización que aspira a ser ágil.

El rol del dueño de producto

En el último artículo de mi serie “El desarrollo de software son conversaciones”, yo mismo escribía sobre el rol del dueño de producto:

El rol de dueño de producto es, en esencia, un facilitador de conversaciones que tienen que ver con el producto. Insisto en que es un rol, y no un puesto, porque no creo que sea imprescindible implementarlo en todos los casos como una cajita del organigrama. Creo que las responsabilidades y habilidades para desarrollar este rol pueden estar perfectamente desplegadas en el seno del equipo, de una manera autoorganizada. Lo he visto, y funciona.

Es cierto, un buen equipo de definición de producto es multidisciplinar y trabaja y toma las decisiones de manera colectiva. Así, a veces es el experto en la experiencia de los usuarios (UX) quien influye más en las decisiones, otras veces es un experto en la tecnología quien advierte de ciertos riesgos,otras veces será un analista de negocio quien explicará cómo funciona un cierto proceso, en muchas ocasiones es el experto en asegurar la calidad (QA) quien enfrenta al grupo a encontrar el mejor plan iterativo e incremental para construir y desplegar el producto, etc, etc. Puede haber muchos más roles, pero la clave está en que todos se pueden autoorganizar para tomar las mejores decisiones. ¿Cuál es el problema si llamamos Product Owner a todo el equipo?

Ojo, no estoy en contra de que un equipo tenga a una sóla persona ejerciendo un rol, ni siquiera defiendo la “pureza” en la implantación de tal o cuál metodología. Defiendo a muerte que cada cuál haga lo que le funcione, siempre y cuando sepa lo que está haciendo, comprenda y acepte las implicaciones de ello y no confunda los términos. No soy un “talibán del Agile”, pero me gusta que seamos rigurosos porque es una forma de respetar a los demás.

El rol del ScrumMaster

Y no me quiero centrar en el caso del rol del dueño de producto. Justo a continuación, en el mismo artículo, abundaba sobre el rol del ScrumMaster (en los equipos que hacen Scrum):

Lo mismo podría decir del rol del ScrumMaster, que normalmente pondrá más foco en facilitar las conversaciones que tienen que ver con los procesos y las personas. Como antes, creo que es un rol que cuando es desempeñado de manera autoorganizada, dota al grupo de una mayor corresponsabilidad respecto de la mejora continua.

Es fácil encontrar al ScrumMaster organizando el trabajo del equipo y ejerciendo, de alguna manera, de jefe de proyecto. Insisto, por más que duela, el jefe de proyecto ha muerto. Yo suelo sugerir que, al principio de la vida de un equipo, el puesto de ScrumMaster vaya siendo ocupado de manera rotatoria por todos los miembros del equipo. Por un lado esto ayuda a que todos entiendan y empaticen con el rol. Y por otro lado, es más fácil encontrar a aquellas personas que se les da mejor y a quienes se les da peor. A partir de ahí podemos tomar decisiones como, por ejemplo, que una persona ejerza ese rol con plena dedicación, u organizar formaciones para completar habilidades, etc. Así, el equipo ha decidido cuál es su organización y se sentirá dueño de reorganizarse en el futuro si fuera necesario. Si hubiéramos tomado decisiones por ellos, esto sería mucho más difícil de que ocurriera.

El rol del Agile coach

Me molesta sobremanera cómo se está implementando el rol de Agile coach en la inmensa mayoría de las transformaciones ágiles, pues reproducen esta mentalidad de cajas en un organigrama. El Agile coach como parte de una estructura (aunque sea transitoria), con unas responsabilidades definidas como partes de la cadena de valor, me parece lo peor.

Yo veo mi rol como el de un explorador que nace y muere (metafóricamente) para enseñar a sus compañeros a convertirse en una organización que aprende a adaptarse a los cambios. En ese sentido, es contraproducente convertirse en el encargado de, por ejemplo, facilitar ciertas ceremonias.

El Agile coach debería acompañar en el camino hacia una nueva organización donde algunos miembros de la misma son capaces de facilitar sus propias ceremonias. Quiénes, cómo, cuándo, e incluso porqué forma parte de la exploración que haremos juntos. Para ello es muy posible que yo facilite las primeras ceremonias, pero con el objetivo explícito de que otras personas tomarán el testigo lo antes posible. Pues sólo practicando podremos aprender si es eso lo que debemos hacer.

E igual que hablo de facilitación de ceremonias hablo de muchas otras decisiones, como el diseño de procesos, de definición de roles, etc, etc.

En la foto que ilustra este artículo he dibujado una jerarquía “ScrumMaster”, “Agile coach”, “Head of Agile coaches”, que me temo que es demasiado frecuente. Probablemente esto requiera un artículo en exclusiva. De momento diré no me parece nada más que el resultado de la comoditización de estos roles. La industria los está adoptando y buscando dónde encajan para poder venderlos mejor. Así, el Agile coach se vende como un ScrumMaster senior o un ScrumMaster con mayores responsabilidades, quizás como responsable de un equipo de ScrumMasters. E igual nos encontramos con Agile coach Enterprise frente al Agile coach normal. O un Head of Agile coaches, que se distingue del resto porque gestiona a un equipo de Agile coaches. En fin, nihil novum sub sole. Quizás deberíamos hablar sobre cómo podemos evitar este efecto industrializador que devalúa el sentido de las cosas.

Conclusión

En mi opinión, si implementamos los roles como cajas aisladas, estamos dando más importancia a los procesos que a las interacciones y primando los contratos frente a la colaboración. Estoy convencido de que podemos y debemos aspirar a otro tipo de organización, donde todos seamos corresponsables de las decisiones y los resultados.