Tenemos claro que todas las organizaciones estamos avanzando en la implementación de prácticas Agile. Cada una a nuestro propio ritmo, según nuestras circunstancias y la propia cultura de la organización. En algunas, las menos, se ha optado por un cambio radical en el modo de funcionamiento de toda la compañía. Un día “nos acostamos” trabajando de una manera convencional, y al siguiente “nos despertamos” teniendo que seguir un modelo de trabajo y organización completamente nuevos.

En otras, según el caso más frecuente, se define un ámbito de aplicación para poder introducir esta transformación, de manera que se pueda comenzar a adquirir práctica y conocimiento sobre el nuevo modelo de una forma pequeña, y poder ir extendiéndolo en función de las necesidades, los resultados, o simplemente la capacidad de la organización para asimilar transformaciones.

Pero ¿que sucede cuando nos encontramos en medio de una transformación y debemos iniciar otra? Recientemente, Chris O’Malley (CEO de Compuware) y Gene Kim (autor, entre otras cosas de “The Phoenix Project”) han tratado esta situación en un artículo de Information Week bajo el ingenioso título de “DevOps no es una palabra sucia”.

Los autores plantean la situación de que en una organización que ya ha pasado por la introducción de varias novedades, se propone la implantación de un modelo DevOps. Como sucede frecuentemente, y ya tratamos en estas páginas hace algunos meses, habrá un grupo de Innovadores y Early Adopters que aplaudirán la nueva iniciativa, y la verán como una oportunidad para respaldar y acelerar la transformación en curso. Mientras que otro conjunto de personas, a quienes llamábamos “Rezagados” en al anterior artículo, se opondrán al nuevo cambio- La mayoría, el resto del personal, se quedarán a la espera de ser convencidos por unos o por otros.

El problema de esta situación está en que ahora los “Rezagados” cuentan con una batería de razones mucho más sólida que en la ocasión anterior. A cualquiera nos resulta sensato el argumento de que la aplicación de cambios debe hacerse con precaución. Es decir, que hasta que no hayamos completado una ola de transformación, no deberíamos arrancar la siguiente. Y podrán apalancar sus argumentos en la constatación de los errores que, inevitablemente, hayan podido aparecer en el camino de la transformación, obviando los indudables beneficios obtenidos y los resultados alcanzados.

El principal problema que plantea esta visión reactiva es que nuestras organizaciones no pueden permitirse el lujo de detenerse hasta que se den las condiciones idóneas para introducir nuevas reformas. Si esta fuera la decisión. la organización estaría dando el primer y fundamental paso para su propia catástrofe. Antes bien, como se mostraba en en el legendario anuncio de EDS en el que construían un avión en vuelo, nuestras organizaciones necesitan incorporar las transformaciones cada vez con mayor celeridad, pues ni la competencia, ni los clientes van a esperar a que estemos listos.

En el caso del artículo que os recomiendo plantean esta circunstancia referida a la adopción de DevOps por una organización que ya haya avanzado en la adopción de prácticas Agile. Y hacen una serie de recomendaciones para que la adopción pueda ejecutarse de una forma más elástica, tratando de solventar las resistencias. No os sorprendo si os digo que mantener el foco en la estrategia, implicar intelectual y emocionalmente al personal y la obsesión por la satisfacción del cliente son 3 de los 5 puntos que ofrecen para lograr la adopción de un cambio sobre el cambio… a la espera de la siguiente revolución.

¿Y tú? ¿Has tenido esta experiencia en tu proceso de transformación?

Imágen: ShotPot en pexels.com.