Aprendizajes iniciales

Los principios para priorizar y lanzar Agile en una organización

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:

  1. Orientarse a solucionar problemas.
  2. Tratar a cada persona en función de su receptividad a Agile.
  3. Hacer un rediseño organizativo para impactar sobre la cultura.
  4. Es un piloto, hay que utilizar reglas diferentes.
  5. El lenguaje inicial tiene que ser sencillo de entender.
  6. Tener feedback regular de los cambios para saber qué gestionar.
  7. Introducir Agile gradualmente.

agiletransformation_principles.PNG

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 de 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 no excluye solucionar también problemas importantes para los equipos de trabajo, pues 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 equipos, sobre todo cuando no están integrados transversalmente, con lo cual no son equipos autónomos para poder entregar valor por sí mismos y hasta tienen conflictos entre ellos para conseguirlo. Necesitaremos que el Senior Management acabe promoviendo el rediseño organizativo necesario para integrarlos, en favor de los objetivos globales.
  • Esto quiere decir que cualquiera que sea el impedimento más importante que nos encontremos para conseguir flujo de valor (o problema para el Senior Management), ese tendrá que ser el principal impedimento a priorizar (o el que nos ayude a saber qué cosas hay que cambiar).
  • Consecuentemente, en el inicio de una transformación hay que tener conversaciones con el Senior Management sobre cuáles son los problemas que más les gustaría resolver (o 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 entender a todos si hay o no una “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 el 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, 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).

agiletransformation_earlyadopters

3. Hacer un rediseño organizativo para impactar sobre la cultura

La estructura tradicional de “equipos” y roles (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”, hay 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 la de permitir que los equipos piense 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, 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 añadir 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 requisitos 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”. En esa conversación, quien interactue con ese CXO irá con una vestimenta similar a la suya, si es traje, pues habrá que vestir con casi traje. 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 hable 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

1 comentario en “Los principios para priorizar y lanzar Agile en una organización”

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s