Los 6 errores que Salesforce no cometió

Tiempo aproximado: 8 min.

Llevo ya varias semanas (¿meses?) leyendo “The Age of Agile”, de @stevedenning. Soy muy lento, pero es que además el libro es muy interesante y lo voy subrayando todo el rato. Si te interesa comprender mejor el impacto del agilismo en la forma en la que las empresas tienen que trabajar en un mundo de constantes cambios, te lo recomiendo sin duda.

El otro día, mientras lo leía, me encontré con un apartado titulado “Cambio “big bang”: los 6 errores que Salesforce no cometió”. Me ha parecido especialmente interesante y quería compartirlo. Se trata de un resumen al que he añadido algunos comentarios de mi propia cosecha.

El contexto es 2006, cuando la directiva de Salesforce (fabricantes del más exitoso CRM del momento distribuido en formato SaaS) se da cuenta de que la innovación en la compañía estaba comenzando a ser demasiado lenta para garantizar el futuro de la compañía. Así que decidieron hacer como otras muchas compañías de software: una implementación masiva a modo de “big bang” de prácticas ágiles a lo largo de toda la organización… con un éxito considerable. Denning explica los 6 principales errores que se suelen cometer al implementar Agile pero que, en el caso de Salesforce, ellos consiguieron evitar. ¿Cuáles son estos errores?

Error 1

Introducir el cambio como otro-proceso-de-negocio-más

Agile no sólo se trata de nuevos procesos sino también de nuevas maneras de pensar, hablar y actuar con todos en el trabajo. Sin embargo, es típico tratarlo como un proceso más, probablemente dentro de un plan de transformación o algo por el estilo.

En Salesforce se anticiparon a la tensión que iba a provocar la convivencia de dos estilos de gestión contrapuestos. Por suerte para ellos, en su caso se dieron 3 elementos que ayudaron a que este error no se cometiera:

  • el modelo SaaS encajaba perfectamente con los métodos iterativos de desarrollo de producto,
  • en Salesforce ya tenían una extensa batería de pruebas automatizadas que permitían entregas frecuentes,
  • en la mayoría del área de I+D la gente ya estaba colocalizada, es decir, ya se sentaban cerca unos de otros.

Error 2

La alta dirección apuesta sobre seguro

Si el cambio tiene éxito, ellos lo celebrarán como propio. Si fracasa, dirán que no fue idea suya y que no es más que otra moda pasajera. Lamentablemente esto ocurre mucho.

Lo que sucede en estos casos, en mi experiencia, es que en la empresa hay una cultura punitiva que castiga al que se equivoca. Yo lo suelo caricaturizar con el ejemplo de un ejecutivo que no se arriesgará a perder la plaza de aparcamiento en la empresa: símbolo de su status. Sin embargo, no hacen menos de lo que se esperaría de cualquier otro ser humano en este contexto.

Por suerte para Salesforce, los miembros de la alta dirección dejaron claro desde el principio que estaban comprometidos con el cambio. Estuvieron allí en los momentos críticos de la transición, cuando se ponían a prueba los límites. Denning pone como ejemplo la decisión de respetar la fecha de entrega a toda costa, aunque no hubiera nada que entregar y los equipos pidieran más tiempo para completar funcionalidades importantes.

Error 3

Aplicar rígidamente una metodología concebida en otro lugar

Como ya expliqué en mi reciente charla de “Los estados intermedios”, la introducción de Agile en una organización es una transformación cultural y, por tanto, es un problema en el dominio de lo complejo, por lo que no es acertado importar directamente lo que haya funcionado en otro sitio, sin adaptarlo al contexto. Muchos se empeñan en implementar exactamente la misma terminología, definir los mismos roles y los mismos procesos, como si de una receta se tratara. Y todo porque en otras organizaciones sí funcionó.

Ya lo advertía @henrikkniberg en 2015 en relación al llamado “modelo Spotify”:

Así que aparentemente, sí, las empresas pueden copiar modelos de otras, y a veces esto puede ser útil – mayormente porque casi siempre es valioso mirar a tu propia organización con una mirada crítica, y tomar inspiración de otros. Siempre y cuando lo adaptes a tu contexto local (lo cuál termina haciendo la mayoría, con el tiempo).

Cuenta Denning que en Salesforce, lejos de todo esto, elaboraron un documento describiendo el nuevo proceso, sus beneficios y por qué la compañía estaba cambiando. Organizaron 45 reuniones de 1 h con gente clave de todos los niveles de la organización. Al final de cada reunión incorporaban el feedback de la misma para crear una nueva versión del documento. De esta manera consiguieron un amplio respaldo para el cambio, permitiendo a mucha gente participar en el diseño del mismo y sentirse parte activa de la solución.

Además, un equipo ya había conseguido llevar a cabo un proyecto de gran visibilidad usando métodos ágiles. Esta experiencia ayudó cuando el cambio fue introducido en otros equipos, pero no para copiar las prácticas que habían funcionado para ese equipo sino para enfocarse en los principios. Cuando los equipos tenían un problema, siempre podían ajustar aquellas prácticas que pensaran que no encajaban en su caso.

Error 4

Microgestionar el cambio

Agile implica que los managers deben cambiar su papel de supervisores de individuos a habilitadores de equipos auto-organizados que trabajan en ciclos cortos de trabajo. Eso implica crear el espacio donde las personas que realizan el trabajo tengan la autonomía para aplicar todo su talento y creatividad para producir algo que guste a los clientes. En efecto, el poder ya no está en el “jefe” sino que el nuevo “jefe” es el cliente.

Dice Denning que si este cambio de estilo de gestión es impuesto desde la alta dirección, el nuevo enfoque corre el riesgo de ser interpretado (legítimamente) como una continuación del estilo de dirección de arriba-a-abajo y de comando-y-control. No podría estar más de acuerdo.

En Salesforce, sin embargo, incorporaron un nuevo estilo de gestión basado en señalar una dirección y habilitar a las personas para dirigirse hacia ella, en vez de dar instrucciones detalladas y controlar el cumplimiento de las mismas. Este cambio fue liderado por un equipo multidisciplinar dedicado. El equipo fue empoderado para que tomara decisiones y usara la nueva metodología en su propio trabajo. Trajeron expertos de la industria y de otras compañías que habían adoptado técnicas similares. Crearon una programación global para el proceso completo, proporcionando acompañamiento y guía, identificando y eliminando impedimentos sistémicos, monitorizando el éxito y evangelizando sobre la nueva manera de trabajar en toda la organización.

Claves para este cambio fueron:

  • poner foco en los resultados de los equipos en vez de en la productividad individual,
  • formar equipos multidisciplinares que se encontraban diariamente.

Todos los equipos usaban un proceso iterativo simple con un vocabulario común y con trabajo priorizado para cada iteración. El resultado fue que empezaron a hacer entregas cada 30 días. Imagino que antes serían mucho menos frecuentes.

Error 5

Mantener secretas las decisiones clave de gestión

La jerarquía burocrática adolece de una notoria falta de transparencia. Cada capa de la organización tiende a decirle a la capa por arriba y por abajo lo que quieren escuchar, en vez de todo lo que necesita ser conocido. Es típico que la gente “cubra su trasero” (Denning usa la expresión “CYA routines”) a lo largo de toda la jerarquía, de modo que para saber lo que realmente sucede es necesario acceder a redes informales. Introducir Agile en este contexto corre el riesgo de sufrir de serios problemas de comunicación y malentendidos.

En contraste, Salesforce abrazó el principio de sinceridad total. Todas las reuniones diarias tenían lugar en un espacio público, delante de un tablero, de modo que todo el mundo podía ver cómo iban las cosas. La disposición a compartir información con todo el mundo habilitó a la gente para adaptarse diariamente a lo que realmente estaba sucediendo.

Error 6

Escatimar en formación y acompañamiento (coaching)

Según Denning hay estudios que muestran los grandes beneficios para la productividad de los equipos que trae incorporar a coaches externos. La gestión tradicional tiende a ignorar estos estudios porque en su modelo mental, los gestores son los responsables de la productividad. Así, el autor defiende que cuando el futuro de la organización depende del éxito, escatimar en coaching puede ser una manera muy contraproducente de economizar.

Sobre esto tengo una opinión particular muy fuerte. Personalmente no soy amigo de contratar a “hordas” de Agile coaches externos, seguramente porque tampoco soy partidario de este enfoque de transformación “big bang”. Creo firmemente en que el papel del Agile coach es temporal y que debe tratar de que sean personas de la organización quienes propaguen el cambio a todos los rincones de la organización de manera sostenible. Para ello es necesario que les ayudemos a adaptar sus capacidades y competencias para que ellas mismas puedan modelar sus nuevos roles y desplazar así a los Agile coaches.

En el caso de Salesforce, ellos pusieron un gran énfasis en proporcionar toda la formación y acompañamiento (coaching) necesarios. El proceso arrancó enviando a un numeroso grupo de personas (inicialmente todos los directores de área y programa) a una formación diseñada por el equipo multidisciplinar que citaba más arriba. Además, también dieron formación a los “clientes internos”, que al fin y a la postre serían quienes habrían de actuar como “dueños de producto”. Debo decir que cada vez es más frecuente ver que se pone el foco en formar a los mandos altos e intermedios antes que al resto. Formaciones como las de Management 3.0 (los amigos de Netmind lo explican muy bien aquí) u otras más a medida, como en las que participé en eDreams diseñadas por el departamento de formación interna, tienen un efecto muy beneficioso en el cambio de mentalidad de los que luego deben habilitar el cambio en el resto de la organización.

Cuenta Denning que, en Salesforce, incluso crearon una wiki interna como referencia para todo el mundo a medida que se iba desarrollando la transición a la nueva metodología y para informar acerca del propio proceso de cambio. Debo decir que esto mismo lo pongo en práctica en cada sitio por donde paso y me parece una de las herramientas más poderosas y de menor coste para ayudar en el cambio progresivo de una organización.

Conclusiones

Denning acaba este listado de errores no cometidos y se para ahí. El libro sigue, claro. Sin embargo yo creo que merece la pena compartir mis conclusiones. Para mí, las principales son que:

  • antes de nada hay que conocer el contexto donde se va a producir el cambio, la cultura pre-existente,
  • hacer que todo el mundo sea parte activa del diseño de la nueva organización es esencial,
  • es mejor dar pocas recetas y, a cambio, habilitar a todo el mundo para aprender experimentando.

Hay dos reflexiones de fondo más que me gustaría también abordar brevemente.

La primera es que la manera en la que Salesforce evitó errores frecuentes no es garantía para que otros también los eviten. Es más, ni siquiera me atrevería a decir que todo lo que aquí identificamos como errores lo sean en todos los casos. Por ejemplo, el caso del error 2, en el que parte de la dirección quiere “nadar y guardar la ropa”. No me parece razonable decir “si no están todos de acuerdo, no empezamos”. Por supuesto que se trata de un impedimento, de un impedimento serio, pero si esperamos a que se den todas las condiciones quizás sea tarde para la supervivencia de la organización.

La segunda trata de si lo que Denning describe es una adopción “big bang” o de si todos entendemos lo mismo por “big bang”. Personalmente creo que lo que describe que sucedió en Salesforce no fue lo que yo describiría exactamente como un “big bang” sino más bien como una “explosión controlada”, pues habla de un equipo que fue incluyendo a toda la organización en el diseño de los nuevos procesos. En cualquier caso, sí que parece que todo sucedió muy rápidamente e involucró a toda la organización. No parece, desde luego, un proceso lento y guiado por un plan de adopción gradual. Ambos enfoques tienen pros y contras. Eso también lo explica Denning en otra parte del libro, pero eso ya te lo dejo a ti. 😉

Me encantaría conocer tus propias conclusiones. ¿Me dejas un comentario ahí abajo o por el canal que prefieras?