Cuando se quiere introducir Agile en un equipo, o iniciar una transformación Agile en una organización, en algún momento se va a necesitar «recibir el permiso» o, mejor, «ser esponsorizado» por alguna persona en una posición jerárquica superior. Esto puede ser relativamente sencillo o… ¡muy complicado!
Algunas ideas importantes antes de hablar con la persona implicada (el posible futuro «sponsor» o «tu jefe») o a la Dirección:
- Un cambio se inicia con un primer paso de Awareness, proporcionando la conciencia necesaria para poder generar el Deseo de cambio [modelo ADKAR]. En este Awareness, la persona implicada tiene que entender qué ganará con ello (solucionar algún problema o ir hacia una visión futura mejor). Hay que recordar siempre que tiene que sentir que con ello se pueden solucionar SUS problemas (cosa que también solucionará los problemas de otras personas, hacia un bien común para la organización, sus personas y sus clientes) o bien que podrá progresar hacia una visión futura mejor.
- Por ello, antes de hablar con la persona implicada, es conveniente conocer suficientemente bien la Situación actual (el contexto), los Problemas actuales y las Implicaciones que tienen. Expresando ese conocimiento se crea una primera conexión emocional, de entendimiento y empatía con el sponsor [SPIN framework]
- No hay que exagerar las expectativas sobre el cambio, porque pueden parecer irrealistas, o que se caiga en desilusión cuando no se cumplan.
- Es importante conocer el tipo de personalidad del interlocutor. ¿Es orientado a la acción e intuitivo (característica que suelen ser la mayoría de managers, especialmente en la Alta Dirección) o bien está más orientado al detalle y necesita ir más paso a paso? Nuestra comunicación se deberá ajustar a su estilo de personalidad para ser más efectiva.
- ¿Podemos apelar a los valores de la empresa (o a sus valores personales) para realizar el cambio? ¿Resuena con aspectos como la necesidad de «mayor colaboración» o que «la gente tiene que estar motivada»?
- Para darle más seguridad sobre su factibilidad, se pueden explicar historias de cosas similares que funcionaron por el hecho de trabajar bajo estos principios.
- Hay que ser concretos con la propuesta y con qué se le pide de su parte.
- Hay que escapar de «tecnicismos» y explicar la propuesta de manera que lo pueda entender cualquier persona, no levantar una barrera con ellos.
- Si es necesario, se puede hablar de una «prueba» (y es posible que realmente sea así) para aprender qué quiere decir trabajar de forma más Agile en el contexto de la organización, si funcionará más o menos bien y/o averiguar en qué aspectos puede crear más fricción. El concepto de «prueba» o «piloto» es importante para no levantar una barrera de entrada porque se interprete que nuestro interés es llevarlo a toda la organización sin estar todavía en condiciones de saber qué quiere decir eso (e igual tampoco tiene sentido).
- Por ello, antes de proponer el lugar donde se podría pilotar el ser más Agile (proyecto, equipo, área, …) es importante preguntarnos si justo allí realmente tiene sentido (si aportará valor) y qué probabilidades de éxito puede tener este cambio (¿realmente hace falta ser más ágil allí, es uno de los lugares donde la organización se beneficiaría de eso? ¿La gente allí tiene la mentalidad adecuada? ¿Es el momento adecuado para ello, o están liados con otros temas y justo ahora no les va bien plantearse este cambio? ¿Tiene suficientes probabilidades de éxito?). Para más detalle, se puede consultar el siguiente artículo: Cómo seleccionar iniciativas donde introducir Agile en la organización.
Presentación donde se muestra en más detalle todos estos conceptos:
Vídeo de Masterclass donde se explican estos slides:
Para saber más:
Transformación Ágil 