Escalar, Estrategia de transformación

Cómo seleccionar iniciativas donde introducir Agile en la organización (2/2)

[Ver pasos 1 y 2 del Funnel de selección en el artículo anterior]

3. Evaluar si la iniciativa / área / equipo está preparada, si es el momento adecuado

Para esta evaluación se pueden considerar los siguientes puntos:

  • Ver si es el momento adecuado. Es mejor que sientan que no se les impone el cambio de modelo de trabajo y organización. Quizás ese posible área / equipo en ese momento está con otras prioridades o proyectos de las cuales no puede desentenderse para hacer un cambio.
  • Ver si es factible crear un equipo dedicado y estable durante todo el proyecto. Para ello habrá que identificar a los que deberán tener un mayor porcentaje de dedicación para cada skill y negociar su “desenganche” a nivel operativo del área donde están, haciendo un plan de traspaso de otros temas que estén llevando.
  • Averiguar si bajo su punto de vista (especialmente de la gente de Negocio del área y de los Champions de la transformación) la iniciativa con el que empezar tiene suficiente interés para ellos, para que sientan una involucración natural, puesto que van a tener que  proporcionar Product Owners con autoridad y dedicación.
  • Identificar y asegurar la dedicación del Scrum Master (en el caso de seguir el marco Scrum).
  • Disponibilidad de recursos financieros para costear el Coaching del equipo.
  • Empezar a mover la identificación y contratación del coaching para que llegue a tiempo.

4. Seleccionar iniciativas con un riesgo acotado (sobre todo al inicio)

El último paso es seleccionar iniciativas con un riesgo acotado (de producto, organizacional, tecnológico o, simplemente, de complejidad) a fin de asegurar buenas experiencias al comienzo de la adopción de Agile, lo que creará tracción sobre las personas pragmáticas de la organización.

Debemos evitar empezar con un proyecto “condenado” o “kamikaze” dado que tendríamos el riesgo de “quemar” la marca. Se podría asociar al método el fracaso inevitable del proyecto, por ser difícil explicar que ha sido por el contexto del proyecto (alcance y tiempos imposibles, equipo o costes no adecuados, dependencias extremas de terceros, posibles cambios de personas clave durante el proyecto, etc.) o por falta condiciones mínimas para trabajar en Agile, como veremos a continuación (mindset de las personas involucradas, equipo autónomo, insuficiente dedicación de sus miembros, tecnología mínimamente desacoplada del resto, etc.).

Es importante identificar los riesgos en las iniciativas seleccionadas y analizar cuáles son mitigables ya, cuáles se van a materializar durante el piloto y cuáles van a quedar como “lecciones aprendidas” (va a ser muy difícil resolverlos en este momento) para que el Senior Management pueda tomar acciones sobre ellos desde el inicio. Especialmente las relacionadas con la autonomía del equipo / iniciativa / área con el resto de la organización:

  • Dependencias con terceros que pueden ralentizar el trabajo del equipo (la mitigación sería integrarlos fuertemente, de manera que formasen parte del equipo de trabajo, no utilizar el método “tradicional” de coordinar prioridades de planes paralelos).
  • Área de trabajo que esté demasiado acoplada tecnológicamente del resto, dado que Agile tiene que poder entregar en ciclos cortos y puede ser necesaria una excesiva coordinación con esas otras áreas.
  • Área de trabajo con una “herencia tecnológica” muy mala, en lugar de encontrarnos una base tecnológica que suple fácilmente las necesidades y bien modularizada, hay parches sobre parches que impiden hacer cambios de manera controlada y sencilla.
  • Incapacidad para tomar decisiones al depender de estamentos superiores, no estar suficientemente empoderados (y para ello capacitados) para moverse rápidamente sin ser invalidados más tarde.
  • Iniciativa que pueda dejar de ser prioritaria en el medio plazo. Tiene que ser suficientemente estratégica como para que merezca la pena la inversión de agilizarla y/o no se cambien a las personas durante el proyecto porque «hay necesidades más prioritarias» en otros.
  • Tener un presupuesto para Agile Coaching, con el objetivo de acompañar a ese equipo en la transformación.

agile-selection-funnel-in-action
Como podemos ver, para la priorización de la transformación de la organización se ha utilizado los mismos principios que para crear un Product Backlog (PBL), pero de transformación de la organización!:

  • Identificar iniciativas o áreas o susceptibles de ser agilizadas (los ítems del PBL).
  • Definir unos criterios de priorización.
  • Ordenar la lista.
  • Desarrollar esas áreas.

Habrá ítems que queden muy abajo. No es problema. Lo que más valor va a aportar a la organización es tener foco en hacer bien los primeros ítems, dejar bien consolidadas las áreas con las que se empieza antes de movernos a las siguientes, para dejar anclado el cambio, crear un sistema sostenible por sí mismo, que las propias personas en su interior sean capaces de accionar y seguir en movimiento por sí solas.

Sin embargo, posiblemente habrá que gestionar el “tiempo de espera“ de los que están en cola para empezar, especialmente si están deseando hacerlo, y gestionar los temas que puedan quedar “descolgados” al hacer la escisión de las primeras iniciativas / áreas. En estos casos habrá que:

  • Comunicar bien que el cambio necesita de foco para anclarlo, que la capacidad de recursos de transformación es limitada y que cada uno tiene su momento por la razón estratégica X que sea, con lo para el resto ser´necesario esperar, quizás algunos meses. Mientras tanto, para ir introduciendo cambios, pueden conversar con los que ya están en la transformación, asistir a algunas ceremonias, formaciones, asistir a Comunidades de Práctica, empezar a practicar-probar por su cuenta y sobre todo, hacer retrospectivas 🙂 (iniciar la cadencia de mejora continua).
  • Identificar qué temas pueden quedar “sin dueño” o qué relaciones con el resto de la organización van a sufrir más en el impass, para gestionarlas de forma proactiva.

Como consecuencia de aplicar este funnel de forma sistemática, se favorecerá a las áreas que más demanden trabajar de esta manera (más receptivas), su transformación será más rápida que las que generan más resistencia (que necesitarían demasiada inversión de recursos para obtener un menor resultado o, en el peor de los casos, quemarían la transformación o a los agentes de cambio implicados en ella). Si el deseo de la organización fuese acelerar también allí (donde hay mayor resistencia), se necesitará un liderazgo fuerte en dejar claro que los principios por los cuáles esto funciona son el mindset de “test & learn”, la colaboración, la transparencia, el empoderamiento de los equipos y quitarles impedimentos de su camino. Cualquier otro tipo de comportamiento no es el deseado en la organización y es posible que haya que tomar medidas al respecto.

Notar que NUNCA va a existir el momento perfecto ni el contexto perfecto para empezar. Hay que moverse, lanzar equipos para abrir camino y que pongan de manifiesto los aspectos más importantes a mejorar para conseguir una organización más ágil.

En todo caso, haber hecho el análisis anterior nos permitirá prever qué problemas nos vamos a encontrar en el área seleccionada y para poder así prepararnos mejor.

Un ejemplo de cómo hacer este funnel de evaluación sería con un Excel (colaborativamente, idealmente con personas que conozcan bien la organización, como las mencionadas en el artículo anterior):

Selection-iniatives-Agile

Notar que las áreas más “digitales” suelen cumplir con las 4 condiciones del funnel:

  • Necesitan ser ágiles en el mercado y ajustar sus productos rápidamente en función de las necesidades de los clientes.
  • Disponen de personas acostumbradas a trabajar «codo con codo» para conseguir resultados en ciclos cortos, abiertas a experimentar y probar cosas nuevas.
  • Dado que se mueven en ciclos de desarrollo cortos, es más sencillo poder introducir cambios en su modelo de trabajo entre proyectos, es decir, empezar uno nuevo con un nuevo método de trabajo más Agile.
  • Suelen disponer de entornos tecnológicos propios bajo su control.
  • Y, sin embargo, dependen fuertemente de la parte transaccional de la empresa, con lo cual,  para ser rápidos y flexibles, tarde o temprano van a tener que integrar especialistas de esas áreas transaccionales (extender el equipo Agile).

Artículos relacionados


Revisión: Vanesa Tejada y Silvia Sistaré

Ilustraciones: Vanesa Tejada

1 comentario en “Cómo seleccionar iniciativas donde introducir Agile en la organización (2/2)”

Deja una respuesta

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. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s