Gestionar las expectativas: ¿Qué entendemos que hace cada rol?

Por Carlos Blé Jurado

Cuando llevamos unos cuantos proyectos trabajados con metodologías ágiles, tendemos a pensar que todo el mundo entiende lo mismo por Product Owner, Product Manager, Stakeholder, Scrum Master, Engineering Manager, Developers, DevOps, Testers…. pero resulta que nos encontramos que cada equipo y cada organización entiende algo diferente para estos roles/culturas.

Asumir que todos compartimos la misma visión y misión de cada uno de estos roles, es arriesgarse a entrar en conflictos por diferencias en las expectativas.

Para trabajar en equipo, es recomendable llegar a un consenso sobre lo que esperamos de cada rol. Si además se puede dar el caso de que una persona pueda ejercer más de un rol, es conveniente consensuar cómo los intercambia ¿Si soy engineering manager significa que, cuando me pongo sombrero de developer, tengo la potestad de tomar decisiones técnicas unilateralmente?, ¿o significa que paso a ser developer igual que los demás developers? En un reciente podcast hablo justo de esta posible mezcla de roles. Es muy esclarecedor tener una conversación con todos los miembros del equipo donde revisemos estos temas, incluso aunque la propia organización haya escrito documentos definiendo los roles, porque eso no garantiza que la gente los lea. Todo el mundo usa las palabras de moda de la agilidad, pero muchos en sus cabezas lo que están haciendo son traducciones del estilo “stakeholder = jefe”.

¿Hasta dónde llega el trabajo de un rol?, ¿dónde empieza el del otro? Cuando decimos que queremos que negocio y tecnología trabajen muy unidos, ¿qué significa exactamente?, ¿los developers deberían explicar el código a los product owners?, ¿hasta qué nivel de detalle técnico y de negocio queremos llegar? Lo mejor es hablarlo, en vez de asumir, porque cada persona asumirá cosas distintas.

¿A qué llamamos equipo?, ¿en las retrospectivas deben estar los stakeholders? (para mí, esto es un rotundo ¡sí!), ¿qué mecanismos de mejora tenemos?, ¿cómo medimos nuestro progreso como equipo?, ¿qué mecanismos establecemos para podernos dar feedback entre las personas del equipo?, ¿se quiere poder dar y recibir feedback? Para nosotros, por ejemplo, es importante recibir feedback desde todos los ángulos posibles (360) y por eso pedimos feedback continuo. Es la forma en que podemos mejorar y la mejora continua es parte de nuestra cultura.

Más allá de los roles, conviene definir la forma en que nos vamos a comunicar. Qué canales son los más adecuados para qué cosa e incluso cuáles son los tiempos de respuesta esperados en cada medio si hiciera falta ¿Qué momentos son los más adecuados para conversar?, ¿se puede interrumpir a cualquier persona en cualquier momento, para cualquier cosa?, ¿queremos ser rígidos en la definición de estos protocolos o vamos a ser más flexibles y a iterar?, ¿cómo vamos a iterar?

En el caso de que haya una cadena de personas entre quien escribe código y quien lo paga o lo pide, ¿puede la persona que programa hablar directamente con la stakeholder?, ¿se ofende alguien de en medio de la cadena si no se le cuentan las cosas a ella primero?, ¿hay algún límite o restricción de temas que no se puedan hablar entre diferentes departamentos o jerarquías? Típicamente, la forma en que descubrimos las respuestas a todas estas preguntas es a base de cometer errores y generar crispación sin querer, ¿no sería mejor intentar aclararlo antes de forma directa?

Acordar periódicamente quiénes son las personas que deben o no deben estar en ciertas reuniones, ayudará a evitar el desperdicio que suele producirse cuando todos van a todas las reuniones por miedo a que alguien se moleste o porque no saben si deben ir o no ir. Las reuniones cuestan mucho dinero y hay que tenerlas, por eso merece la pena planificarlas también en la medida de lo posible y hacer retrospectivas sobre cómo hacemos las reuniones. Lo mismo podría decirse de los hilos de correo o de slack/teams/chat…. ¿todo el mundo debe estar pendiente de todas las conversaciones en todos los canales?, ¿hacemos reuniones diarias (daily standup meeting o similar)?, ¿cuánto tiempo debería durar?, ¿cómo queremos que sea la dinámica de esta reunión?

Tampoco es habitual que los equipos definan un mecanismo de resolución de conflictos antes de ponerse a trabajar juntos y, sin embargo, en todos los proyectos hay momentos de conflicto o por lo menos de tensión ¿Qué debemos hacer ante una situación de tensión?, ¿contamos con la figura de mediador/a para ayudar?, ¿hay que escalarlo a alguna otra persona?, ¿en qué momento? Para nosotros es un tema que es importante consensuar con los equipos en los que trabajamos.

¿Cómo gestionamos los conflictos de interés? Por ejemplo, la reducción de bugs o la deuda técnica frente al desarrollo de nueva funcionalidad. La visión tecnológica de la compañía frente a la visión funcional ¿Qué espacios hay disponibles para tratar estos temas? ¿Cómo es el proceso de toma de decisiones en el equipo?, ¿es democrático, es sociocrático, es “jefista”…?, ¿todo el mundo puede opinar sobre un cada tema?, ¿se necesita alguna formación específica?

Los equipos que trabajan con más velocidad y más agilidad son aquellos donde reina la confianza. Es el ingrediente básico de un equipo de alto rendimiento, pero la confianza no se puede solicitar, sino que hay que ganársela. De esto habla muy bien Stephen M R Covey en Speed of Trust (traducido como El factor confianza). Para ganar confianza debemos de estar alineados en las expectativas. Las expectativas no cumplidas provocan desconfianza.

¿Qué prácticas ponéis en marcha cuando arranca un equipo nuevo?