La agilidad ha llegado a muchas empresas, cada vez se está expandiendo más. Agile suele ser una parte de Recursos Humanos a nivel organizativo, esto ocurre sobre todo en empresas con cierto tamaño. En otras empresas, Agile dispone de su propio espacio e incluso su silla en el Comité de Dirección.
Cuando Agile evoluciona a Departamento, necesitamos dotarlo de las mismas características que el resto de departamentos: Responsables, Procesos, Organización, Carrera… ¿Ponemos orden al Departamento Agile?
Justificando las Tarifas
Barry Overeem, una referencia dentro de los Professional Scrum Trainers de Scrum.org lo siguiente:
“Las empresas de consultoría y las agencias de capacitación fomentan esta forma de pensar porque es fácil de combinar con sus crecientes tarifas por hora y sus costosos programas de capacitación. Observe la contradicción con los servicios que brindan estas organizaciones: aconsejar a los clientes que piensen en “estructuras horizontales” que promuevan las capacidades de autoorganización de los equipos, pero promuevan una “estructura vertical” porque funciona bien desde una perspectiva comercial y de marketing”
Es decir, las empresas se siguen organizando piramidalmente incluso en el área de agilidad. En el caso de las empresas consultoras porque es la mejor manera de explicar a un cliente porqué una persona tiene una tarifa el doble de alta que otra. En principio, tiene sentido con nuestra experiencia pero, ¿qué promueve la agilidad?
Menos etiquetas y más habilidades (skills)
Scrum sufrió un curioso cambio a partir de 2020 cuando eliminó la palabra “rol”. Antiguamente, un Scrum Team estaba compuesto por el Scrum Master, Development Team y Product Owner. Dentro del Development Team no existían etiquetas, todos sus miembros eran similares con una responsabilidad compartida.
Sin embargo, dentro del propio equipo Scrum aparecían diferencias entre cada rol, lo que provocó que eliminaran las etiquetas. De hecho, Scrum ahora se centra mucho en la capacidad de un Scrum Team de entregar valor y evita separar internamente. De hecho, para mantener el concepto de Scrum Master y de Product Owner, se incluye el concepto de accountability, es decir, quién es la persona que rinde cuentas por ciertas acciones clave.
Por ejemplo, el Product Owner es el accountable de que el Product Backlog esté ordenado buscando la maximización de valor o los Developers son accountable de la construcción del producto.
El objetivo de este cambio es evitar las etiquetas personales ya que estas crean parcelamientos mentales. Explico algunos ejemplos:
- Soy el Front, yo no hago Back
- Eso es tarea de la Arquitecta
- El UX solo lo toco yo
Para evitar estas actitudes, eliminamos todas las etiquetas y nos centramos en las habilidades de cada personas del Scrum Team. De hecho, es muy sano preguntarle a cada persona ¿Qué sabes hacer? ¿Qué habilidades (skills) disponemos para el equipo?
Y es curioso, casi todas las plataformas de búsqueda de empleo lo primero que miran es tu etiqueta y apenas se centran en las habilidades de las personas. En Linkedin, la sección de habilidades apenas se utiliza.
¿Qué hacemos en las empresas grandes?
Imagina que tienes un equipo pequeño que desarrollar un producto. Al principio, puede que no necesitemos ni responsables, podemos organizarnos para sacar adelante el producto. Sin embargo, empezamos a ser un equipo grande de diez o quince personas y decidimos tener un responsable que organice al grupo. Con el tiempo, el éxito sigue y queremos construir un segundo equipo en otra ciudad para mejorar las ventas. En ese caso, disponemos a un responsable para cada ciudad y un responsable global de producto que organice el trabajo de todos. ¡Y el éxito continúa! Para lo que vamos a expandirnos a otros países, por lo que ahora necesitamos al responsable global, al de cada páis, al de cada ciudad… Un día, descubrimos que para un equipo de apenas 50 personas, tenemos más de 5 niveles de jerarquía. ¿Nos ayudará esta estructura a entregar más valor?
Las empresas usan la jerarquización como una estrategia habitual durante su crecimiento piensan que es lo correcto, nos permite mayor organización. Sin embargo, en entornos del conocimiento, donde los equipos son los que realmente construyen el valor, el llenar el día a día de reuniones, procesos y documentos suele entorpecer. La sensación con tantos niveles es que no está claro quién tiene que tomar la decisión, por lo que muchas veces tenemos que sumergirnos en la burocracia tratando de que podamos avanzar.
En vez de construir equipos autónomos que entreguen valor y que tengan todo el apoyo de su empresa, llenamos de jefes que nos garanticen un orden, hasta que todo se enmaraña tanto que es difícil que el trabajo avance. Realizar la transición entre la jerarquía clásica hacia equipos autogestionados que entreguen valor es difícil pero es nuestra principal ocupación. ¿Por qué no predicamos con el ejemplo?
El Departamento Agile
Agile vive en un eterno dilema. Sus propuestas son radicales con respecto al statu quo de muchas empresas actuales lo que genera muchos choques. Hay personas que definen que los diferentes marcos, prácticas o técnicas se adapten a la realidad de sus empresas y hay personas que prefieren la esencia original.
Los que prefieren la adaptación suelen vivir muy bien al principio. Al edulcorar lo que supone Agile para una empresa, conseguimos que nos escuchen y que acepten nuestras propuestas. En el fondo, les estamos prometiendo trabajar de la misma manera pero con anabolizantes, ahora los equipos van a ser “ágiles” y van a correr. Por eso, cuando organizamos el Departamento Agile como una jerarquía con niveles, conseguimos que los demás nos entiendan. ¡Es más! incluso les impresiona la cantidad de nombres tan “guays” que tenemos: Enterprise Agile Coach o Scrum Master, ¡esto tiene buena pinta!
Y de ahí surgen los diferentes niveles que puede tener una comunidad Agile. Además, es habitual que empecemos a disponer reuniones por “niveles” y cambiar las responsabilidad. Muchas personas siguen pensando que el Agile Coach es una figura que está “por encima” del Scrum Master y que su función es a nivel empresa, cuando los Scrum Master son los que realizan dicha labor trabajando con equipos que están en el “barro”.
Si seguimos mirando a nuestro equipo como “poco maduro” en vez de dejarles trabajar desde los equipos hacia la empresa, difícilmente conseguiremos que crezcan profesionalmente. Scrum o Agile buscan el valor desde los equipos, no desde las grandes capas de las empresa, aunque tenemos que trabajar con ellas.
Trabajando por Habilidades
Un equipo Agile debería mostrarse plano ante el resto y solo discernir por las capacidad que cada persona tiene. Lo ideal es tener una matriz de habilidades donde cada profesional explique aquellas áreas que domina y cuáles está trabajando. Por ejemplo:
- María es una crack trabajando con equipos Scrum
- Paco no es técnico, pero trabaja bien con equipos de RRHH
- Natalia es muy técnica y domina XP, podría mentorizar equipos
- Juan es muy bueno con escalado, pero no tiene inglés, cuidado.
De esta manera, disponemos de un equipo con diferentes habilidades con las que podemos trabajar. De esta manera enseñamos a la organización como es la visión de un equipo ágil, dispuesto por personas que trabajan juntas para entregar valor en vez de debatir cómo encajar las piezas y que haya trabajo suficiente para cada etiqueta.
Hay quién le preocupa la definición de carrera profesional, simplemente puedes definir qué habilidades suman para tener un mejor salario o dejar al equipo organizarse salarialmente en base a méritos y trabajo en equipo. Es difícil al principio porque no estamos acostumbrados pero asumir una responsabilidad como la salarial desarrolla profesionales más cualificados. ¡Empecemos a entrenar a los profesionales!
Y tú, ¿te organizas en una Jerarquía Agile?
