En la introducción de Agile en una organización, hay varios principios que nos pueden ayudar y que hasta nos servirán para priorizar las iniciativas estratégicas / áreas / equipos donde empezar con Agile:
- Orientarse a solucionar problemas.
- Tratar a cada persona en función de su receptividad a Agile.
- Hacer un rediseño organizativo para impactar sobre la cultura.
- Es un piloto, hay que utilizar reglas diferentes.
- El lenguaje inicial tiene que ser sencillo de entender.
- Tener feedback regular de los cambios para saber qué gestionar.
- Introducir Agile gradualmente.
1. Orientarse a solucionar problemas
La gente sólo se mueve / cambia por algo que le produce un beneficio o le soluciona un problema: cumplir con los objetivos que le han puesto, ordenar su caos, aprender algo nuevo especialmente importante, ganar reconocimiento, promocionar en la empresa, …
- En realidad no estamos “introduciendo” Agile, el objetivo es resolver problemas:
- Problemas en el flujo de valor, desde la idea hasta su uso por un cliente final y recoger rápidamente su feedback como entrada para siguientes pasos.
- Problemas de personas, en especial problemas del Senior Management, de esta manera nos aportarán sponsorship a la iniciativa de «agilización».
- Notar que eso por supuesto también incluye solucionar problemas importantes para los equipos de trabajo, pues (1) lo que se trata es de mejorar la efectividad y el flujo de la cadena de valor, dar sentido a su trabajo (propósito) y (2) ellos después nos harán de embajadores «sociales» del cambio al hablar con sus colegas (de negocio o técnicos) de cómo esa nueva forma de trabajar les ayuda.
- Problemas entre diferentes áreas, sobre todo cuando todavía no están suficientemente integradas transversalmente, con lo cual todavía no son equipos autónomos para poder entregar valor por sí mismos y hasta tienen conflictos entre ellas para conseguirlo. Necesitaremos que el Senior Management acabe promoviendo el rediseño organizativo necesario para integrarlas, en favor de los objetivos globales.
- Así pues, tendremos que identificar los impedimentos más importantes que nos encontremos para conseguir flujo de valor (o problemas para el Senior Management), priorizar su resolución o analizarlos sistémicamente para saber qué cosas hay que cambiar.
- Por ello, en el inicio de una transformación hay que tener conversaciones con el Senior Management sobre cuáles son esos problemas que más les gustaría resolver (o la visión de lo que les gustaría que sucediese), donde quede claro cuáles serían los peores efectos que podrían suceder si no se consiguiese (esto debería ayudar a comunicar la “razón poderosa” para el cambio), y ofrecerles una manera plausible de conseguirlo.
En relación con todo esto, al inicio de una transformación también habrá que analizar qué gana (o pierde) cada persona con el cambio, para poder tener conversaciones en positivo con ellas cuando llegue el momento de su involucración (especialmente el Middle Management, que va a ser fuertemente impactado por la transformación) y que ese cambio se convierta en una oportunidad.
2. Tratar a cada persona en función de su receptividad a Agile
La gente no cambia sus modelos mentales instantáneamente.
- Por un lado, hay personas que van a necesitar ver que esto funciona, otras que van a necesitar tiempo para entender la profundidad del cambio, y por último, otras que no van a hacer «click» nunca.
- Por otro lado, la manera de ser y de relacionarse de cada persona no cambia de forma sustancial en poco tiempo. Es decir, una persona que no es colaborativa no va a cambiar de la noche a la mañana por el hecho de empezar a trabajar en una iniciativa “Agile”.
En relación con esto, no todo el mundo va a ser capaz de trabajar en un entorno Agile (inicialmente o posiblemente nunca), donde son fundamentales la colaboración y el trabajo en equipo para conseguir un objetivo común. Agile no va a encajar con la idiosincrasia de algunas personas (a las que les gusta mandar sobre el resto, a las que prefieren que les digan qué hay que hacer, a las que están muy seguras de cómo se está haciendo el trabajo y no quieren probar cosas nuevas, etc.).
Considerando lo anterior, habrá que tratar a cada tipo persona en función de su receptividad a Agile:
- Empezar con los “early adopters” que ya sean colaborativos por naturaleza.
- Escuchar a los pragmáticos que no están convencidos, dadas las dificultades iniciales en el cambio de manera de trabajar (ellos nos las identificarán y podremos trabajar propuestas con ellos).
- Esquivar conscientemente a los que van luchar / oponerse fuertemente contra esto (“laggards”). Van a aparecer de forma natural (es una cuestión estadística) y nos podrían consumir demasiados recursos (esfuerzo, tiempo, carga emocional). Para ello, tenemos que gestionar el nivel de comunicación con ellos.
- Reducir con ellos la comunicación (al menos inicialmente), para que no utilicen la información que tengan contra nosotros.
- Hablar de “experimentos” que no les van a afectar ( pues es hasta posible que sea así).
- Evitar confrontaciones que nos desgasten por entrar en discusiones emocionales que nos resten credibilidad delante del resto, proyectarían una imagen conflictiva de lo que estamos haciendo, en lugar de la constructiva que estamos buscando. Este tipo de confrontaciones no suman y tenemos que impedir que resten a los demás.
Como consecuencia de todo esto, cómo hacer una transformación Agile depende fuertemente de a quién involucramos (How = Who).
3. Hacer un rediseño organizativo para impactar sobre la cultura
La estructura tradicional de “equipos” y roles (responsabilidades/objetivos que se piden a las personas en ese contexto) determinan fuertemente los comportamientos del sistema.
- Es posible que una organización tradicional encontremos falta de colaboración entre áreas distintas porque, por diseño organizativo, cada área sólo hace “su parte”, se generan diferentes prioridades, etc.
- Es posible que encontremos personas cuyo objetivo históricamente ha sido ser «los únicos responsables» de algo (del éxito de los proyectos, de cómo se trabaja en una especialidad, etc…) por lo cual puede ser que su modo natural de trabajar no sea el de permitir que los equipos piensen por sí mismos sobre qué hay que hacer o cómo hacerlo.
Es por ello que tiene tanta fuerza un rediseño organizativo con equipos autónomos, multidisciplinares y pequeños que tienen una misión conjunta y están empoderados para tomar decisiones, con roles como Product Owner (prioridad única), Scrum Master (equipo de alto rendimiento) y con una nueva misión del Management (entre otras cosas, ayudar a los equipos a que su trabajo pueda fluir, quitando impedimentos organizativos, creando el sistema que permite la entrega de valor al cliente final, desarrollar a su gente para que ganen autonomía, en lugar de entrar a dictar dentro de los equipos que hay que hacer y quién lo hace).
4. Es un piloto, hay que utilizar reglas diferentes
Cuando se lanza un piloto, es posible que aparezcan personas que digan que hay que seguir directivas o restricciones muy concretas heredadas del modo de trabajo actual (respecto a procesos, relaciones organizativas, etc.), lo cual puede ser un gran impedimento a la agilidad del nuevo equipo (no le permite obtener todos los posibles beneficios) y no nos deja probar realmente el modelo (se está haciendo otra cosa, pero no es Agile).
Por ello, habrá que explicar que “un piloto es un piloto”, un lugar donde hay que utilizar reglas propias para que tenga sentido la prueba del nuevo método. Eso no quita que escuchemos lo que nos piden para entender el problema de base que originó la regla tradicional en la organización (más que la solución actual) y, si sigue siendo válido, darle salida bajo un planteamiento más ágil. Hay que esperar que, cuando un equipo multidisciplinar quiera tener cosas hechas por ejemplo cada dos semanas, identifiquemos maneras anteriores de hacer (organizativas, técnicas, etc.) que ya no van a ser suficientemente eficientes y, manteniendo el «para qué» de la regla, se tenga que repensar totalmente el «cómo» (integración de otros roles, habilitación del equipo para realizar nuevas tareas, capacitación y empoderamiento para tomar decisiones, automatización de tareas que sino se harían demasiado repetitivas, etc.).
Respecto a las personas que están más en contra de estos cambios, se sentirán menos amenazadas si se habla de “experimento”, algo con lo que se está jugando, pero que no se está diciendo que se vaya a instaurar, no tiene por qué afectarles en un futuro.
5. El lenguaje inicial tiene que ser sencillo de entender
Hay que tener en cuenta que el modelo de trabajo que vamos a explicar puede ser ya demasiado diferente al actual como para además levantar una barrera adicional con jerga técnica que hay que entender y aprender. Por ello, al inicio de la explicación del modelo es importante utilizar un lenguaje cercano, sencillo de entender. Por ejemplo, puede ser mejor hablar de ciclos o bloques de tiempo (en lugar de iteraciones o Sprints), hablar de lista de objetivos priorizada (en lugar de Product Backlog), hablar de reuniones de sincronización de equipo (en lugar de daily Scrum), etc.
En línea con esto, es conveniente que todo el interfaz inicial de interacción sea lo mínimo de chocante con cada tipo de receptor de la comunicación, que encaje con lo que espera “su tribu” para generar confianza: que te vean que eres de los suyos, con el mismo lenguaje, actitud e incluso vestimenta! Por ejemplo, en la primera interacción con un CxO (en la que se van a explicar conceptos organizativos y culturales bastante diferentes) es mejor que el punto de «distancia» con el interlocutor sean sólo las «ideas» y que el resto de «interface» sea similar a la suya, que pueda pensar: «me explica cosas diferentes pero esta persona es de los míos, sólo que ha vivido otras situaciones, con lo que puede tener sentido lo que está diciendo». En esa conversación, quien interactue con ese CXO irá con una vestimenta similar a la suya, si es traje, pues tendrá que vestir de modo business. De la misma manera, si toca interactuar con personas técnicas, van a conectar más si quien lleva el mensaje no lleva traje (esa persona no sería de su tribu).
Consecuentemente, dado que cada tribu de manera natural “clasifica” y conecta con cada persona en función de a qué tribu más se parece, cómo y con quién interacciona, para cada área de la transformación pueden hacer falta personas con aptitudes diferentes (¿Tiene que hablar managers? ¿Con alguien de producto/marketing? ¿Es un técnico?).
6. Tener feedback regular de los cambios para saber qué gestionar
La transformación de un sistema es un proceso complejo. Una de las bases para controlar sistemas complejos es tener un sistema de feedback que permita ajustar las acciones en cada momento. Por ello es básico disponer de un proceso regular en el que se converse con todos los actores involucrados, con distintas especializades o posición, ya que lo viven desde perspectivas diferentes (equipos, middle management, senior management) acerca de cómo va el piloto o la transformación, qué hay que mejorar.
7. Introducir Agile gradualmente
El principio de “divide y vencerás” (en este caso el alcance de la transformación) es totalmente aplicable, pues ir transformando con foco en segmentos particulares de la organización permite:
- Obtener “lecciones aprendidas” gradualmente, para aplicar en las siguientes partes.
- Disponer de tiempo suficiente para escuchar a las personas implicadas y entender qué cambios se están produciendo (o no) en el sistema.
En esta introducción gradual de Agile en la organización es importante seleccionar las iniciativas estratégicas o áreas que nos servirán como “faro” en la transformación, que nos permitan identificar claramente los aspectos a mejorar en la organización y que servirán como “referencia” y “espejo” al resto donde mirarse.
Como consecuencia de todos estos puntos, es arriesgado hacer una introducción masiva o big-bang de Agile en una organización, se podría generar una cantidad de ruido, desconcierto y resistencia que podría ser difícil de gestionar.
Revisión e ilustraciones: Vanesa Tejada
Transformación Ágil 
1 comentario en “Los principios para priorizar y lanzar Agile en una organización”