¿Puede ser bueno equivocarse?

Tras un tiempo sin pasar por aquí, volvemos a la carga en esta ocasión para comentar algunas ideas sobre implantación del cambio y mejoras en organizaciones. Por supuesto todo lo que se va a comentar se puede aplicar al día a día, no solo a los grandes giros de timón. A ver qué te parece.

Personalmente pienso que los individuos de esta sociedad vemos cualquier tipo de fallo, de equivocación como algo malo, donde lo mejor hubiese sido hacer las cosas de otra manera, y en base a eso, tendemos a culpar o castigar para resaltar que algo en lo que hemos fallado ha estado mal. Es como si quisiésemos evitar cualquier cosa que se salga de lo establecido, de los parámetros comúnmente aceptados. Pon aquí cualquier métrica de calidad, normativa o protocolos que quieras. A la vez somos conscientes de que para conseguir diferentes resultados, es necesario hacer algo distinto, pero es ahí donde tenemos una especie de bloqueo interior: hacer algo diferente implica incertidumbre, la incertidumbre reduce el porcentaje de hacer lo mínimo esperado, aumentan las probabilidades de fallo, por tanto, no lo hago. Prefiero hacerlo igual que siempre, así sé que al menos nadie se va a enfadar, nadie me va a culpar si no sale. Juntos podremos decir que “siempre se ha hecho así” y que “es lo que hay”.

Esto, por supuesto, nos puede llevar muy lejos, incluso a nivel social. Pero no me quiero meter por ese camino. Me gustaría abordarlo desde el punto de vista de la revolución ágil. Sí, en mi opinión, la verdadera agilidad (no estoy diciendo que yo la posea) es a día de hoy todavía una revolución. Henrik Kniberg, seguramente te suene y si no puedes buscar un poco por la web, dio una keynote en Australia en el 2015 donde compartió algunas ideas poderosas. Te recomiendo que veas la keynote si te interesa. Aquí te dejo link.

Henrik cita al CEO de Spotify, Daniel Ek, diciendo que ellos, en Spotify buscan ser los primeros en cometer errores, antes que cualquier otro. Claramente esto pone de manifiesto la cultura del error positivo, que busca sacar algo bueno, incluso de algo que a priori no es tan bueno como un error. ¿Recuerdas que el timón más fuerte de una empresa es la cultura? Como decía antes, esto es aplicable desde a desarrollar nuevas funcionalidades de software hasta implantar un cambio en una organización. Está claro que cuanto más pequeño sea el fallo, menos costará reponerse a él. Con mayor rapidez sacaremos algo bueno y nos adaptaremos. ¡Adaptarse! Si lo recuerdas, dos de los principios de Scrum: inspeccionar constantemente y adaptarse. Corregir aquello que no sale bien. Pero la actitud es muy distinta a la derrotista que da por hecho que del error no puede salir nada bueno y busca ante todo evitarlo.

¿Qué pasaría si dentro de tu equipo ágil transmites una visión negativa ante el error? Pues que el equipo, tras ser amonestado por fallar, tratará de esconder en caso de que ocurra, cualquier error futuro. En vez de aprender de lo sucedido se dedicará a negarlo o a culpar a otra área.

Sin embargo, si le damos una connotación positiva, es mucho más fácil y poderoso aprender a recuperarse del error que el evitar el error por defecto.

Tanto es así, que en Spotify (lo puedes ver en la keynote que te he dejado) han llegado a construir el panel de los errores, y sorprendentemente es algo que puede ayudar a la gente. Cada vez que alguien hace algo mal, consciente y personalmente, se escribe una nota y se cuelga en el panel de los errores, para que tanto esa persona como los demás puedan aprender de ese fallo. No solo para no cometerlo en el futuro, sino para tener presente la lección que nos enseña ese error. Quizás puede llegar a aplicar en otras circunstancias. Y no es una panel de los horrores, de puntos que no deberían haberse cometido, sino que las personas están alegres de compartir con los demás los errores cometidos, ya que eso implica que se están haciendo las cosas activamente, no dejándose llevar por protocolos o normativas que no dan lugar al error.

Un software encarcelado en una jaula es un software que funciona, que no tiene bugs, pero que al fin y al cabo nadie querrá usarlo, porque se habrá convertido en algo obsoleto. Sin embargo, un software con nuevas funcionalidades necesita salir ahí fuera, para que la gente lo pruebe, lo utilice, descubra bugs, y con esos “fallos” convertirse en algo más fuerte, más útil. Lo mismo para una organización, para un equipo.

Obviamente no se trata de buscar el fallo a propósito, pero sí de tener una disposición positiva hacia él. Es más, si sabes que el fallo te traerá algo positivo tras analizarlo, querrás cometerlo cuanto antes y en dosis pequeñitas: falla rápido – adáptate rápido – aprende rápido.

Para terminar, estas ideas son aplicables hacia los demás. En vez de querer tener todo el trabajo de un equipo atado, para que no fallen en la planificación de un sprint, en las funcionalidades priorizadas por el Product Owner, etc., fomenta que se aprenda con facilidad. Es generalmente conocido que Amazon despliega nuevas funcionalidades en su infrastructura cada 11,6 segundos. En vez de hacer esos despliegues algo doloroso, lo hacen algo rutinario. Obviamente se reduce el alcance en cada despliegue con respecto a hacer uno por semana, pero en caso de que algo salgo de modo diferente a como se espera, son capaces de aprender y de adaptarse rápidamente.

¿Cómo son tus reuniones de equipo? ¿Facilitas que tu equipo se recupere con facilidad de los errores cometidos?

Responder

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. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Crea un blog o un sitio web gratuitos con WordPress.com.

Subir ↑

A %d blogueros les gusta esto: