Una transformación agile siempre es un reto para la compañía y las personas que la conforman. Un reto que muchos de los Agile Coach como yo, con un background tecnológico, hemos vivido siempre con una perspectiva desde el mundo del desarrollo y mantenimiento de software y que ahora vamos viviendo con otra perspectiva diferente, la del Business Agility, en la que trasladamos los principios y valores del manifiesto ágil a otras áreas corporativas en las que el trabajo diario tiene escasa relación con el software.
La cadena de confianza del cambio
La resistencia al cambio es una de las primeras dificultades con las que es necesario lidiar al afrontar una transformación agile, y es curioso ver cómo las reacciones que he encontrado en las áreas de negocio se asemejan mucho a las encontradas en el mundo del software. Frases como “esto no me aplica”, o “le funcionará a otros, yo soy diferente”, son tan comunes en negocio como en software, por lo que la manera de apoyar el cambio tiene un eje común: trabajar el cambio de mentalidad de las personas.
La clave sigue siendo hacer el “efecto pinza”, buscando el apoyo de las capas directivas para que empujen el cambio cultural (top-down) y trabajando con los equipos de ejecución para que crean que el cambio es posible y les puede ayudar (bottom-up). La cadena de confianza en los efectos positivos del cambio de mentalidad tiene que empezar en lo más alto de la compañía y no puede romperse en ningún momento, o los beneficios del cambio comenzarán a flaquear.
Identificar agentes del cambio
Tanto si vamos a trabajar con áreas de negocio como de software, es muy recomendable usar técnicas que nos permitan identificar agentes del cambio en la organización. Por ejemplo, Lean Change Management propone una clasificación de la respuesta al cambio de los individuos que nos permite aproximarnos a las distintas reacciones de maneras diferentes. Esta clasificación da lugar a cuatro grupos:
- Movers: apoyan el cambio activamente > Convencer activamente
- Positive movables: no apoyan el cambio activamente, pero su percepción del cambio es positiva > Convencer activamente
- Negative movables: no actúan en contra del cambio activamente, pero su percepción del cambio es negativa > Convencer pasivamente
- Immovables: actúan activamente en contra del cambio > Ignorar
Cada grupo puede atraer hacia su estado a los grupos con una mentalidad más cercana. Es decir, los movers pueden atraer a los positive movables para que no solo crean en el cambio, sino que empiecen a apoyarlo activamente; los negative movables pueden verse atraídos por los positive movables o por los immovables; y así sucesivamente.
Para identificar estos grupos se puede trabajar con técnicas tales como entrevistas personales con los líderes del área, Team Canvas con los equipos, Perspective Mapping, etc.
Técnicas software en áreas de negocio
Cuando entramos en la ejecución del business as usual de los equipos, he encontrado semejanzas con situaciones del mundo del software en las que proponer técnicas que puedan ayudarles a colaborar de un modo más agile. Algunos ejemplos son:
Integración continua:
El intercambio interminable de documentos por correo electrónico con versiones realizadas por diferentes personas cuyo trabajo debe ser mezclado. Me recuerda mucho a esos merge de código insufribles cuando no se integra el código con frecuencia. El uso de una herramienta colaborativa online como los editores que proporcionan G Suite u Office 365 permite hacer un símil con la integración continua, en la que los cambios son integrados de forma inmediata.
Peer review:
La elaboración de un contrato requiere la revisión posterior de otro letrado distinto al que lo elaboró. ¿Quién hará esto? ¿El clásico responsable jerárquico que se termina convirtiendo en cuello de botella? Con una mentalidad más agile, ¿por qué no puede ser un compañero equivalente (peer) el que haga esa revisión más exhaustiva? De esta manera potenciamos la capacidad del equipo para ser autosuficiente en la ejecución de su trabajo y se aumenta el sentido de responsabilidad sobre los entregables.
Pair programming:
Determinados tipos de trabajo han sido tradicionalmente realizados de manera individual, y solo se concibe la opción de un grupo de trabajo cuando la tarea es compleja. ¿Por qué no utilizar la técnica de pair programming para casos complicados, que no complejos, y dedicar a dos personas a realizar ese trabajo conjuntamente? De esta manera obtenemos los mismos beneficios que en el caso del software: mayor garantía de calidad del entregable, mayor aprendizaje de las personas que realizan el trabajo, menor posibilidad de retrabajo, al tener el enfoque de dos personas que pueden empatizar mejor con la necesidad del cliente.
User pain triage:
Las necesidades alrededor de un equipo de asesoría que atiende consultas legales se asemejan mucho a las de otro que atiende consultas tecnológicas o sobre un producto software. Normalmente están sujetas al cumplimiento de un SLA y, si el volumen es muy alto, necesitamos hacer un triaje que nos garantice estar atendiendo primero las consultas que más valor aporten a nuestro cliente. La técnica de triaje basada en asignar puntos en base al dolor del usuario (user pain) puede ser aplicada con similares beneficios en software y negocio.
Agile Coach, técnico en áreas no técnicas… y viceversa
El número de semejanzas entre áreas de negocio y de software a la hora de aplicar una transformación agile que he encontrado es mucho mayor de lo que esperaba, más allá del empleo de este o aquel framework o método para la organización del trabajo. Además, encuentro muy interesante de la buena influencia que podemos ejercer los Agile Coach con background distinto al del área que ayudamos a transformar: he visto muy buenos resultados en áreas técnicas con perfiles no técnicos y viceversa.
Quizás el no poder entrar ni en el “qué” ni en el “cómo” nos hace centrarnos más en la gestión del cambio, independientemente de que sea software o negocio.
Fuente imagen cabecera: Who wants change-Crowd change management, by Alan O’Rourke from audiencestack.com, under CC.
