Como decía Javier hace unas semanas en el post Improvisación aplicada a equipos ágiles, una de las ideas nuevas que nos llevamos del Agile2015 es utilizar técnicas de improvisación teatral para trabajar determinados aspectos en los equipos ágiles, tales como la confianza, el saber escuchar, la empatía, etc. o entender ciertos conceptos propios de la agilidad.
Además de en la keynote de improvisación que comentaba Javier en el post, mi primer contacto con esta idea fue justo en la primera charla que asistí en la conferencia: Improvissing with agile, de Paul Goddard.
Paul dirigió distintas dinámicas de grupo para trabajar 5 áreas que considera importantes en los equipos ágiles: seguridad, espontaneidad, storytelling, status y sensibilidad.
Me encantan las dinámicas de grupo, y siempre voy buscando técnicas nuevas para retrospectivas y talleres (como las que publiqué en Técnicas para motivar a un equipo software y que las reuniones sean más efectivas.), por lo que la idea de una charla a base de juegos y dinámicas me gustó bastante.
Pero lo cierto es que cuando empezamos el taller, con una dinámica en la que una persona hacía de vendedor de una tienda, y otro de cliente y tenían que improvisar una conversación sin decir la letra S…a pesar de sentir que era una actividad divertida me pregunté: ¿y esto qué tiene que ver con la agilidad?
Y noté como muchas personas más de mi mesa se preguntaban lo mismo cuando acabada la actividad, Paul nos dejó 10 min para que reflexionáramos sobre todo lo que había pasado en la dinámica y cómo se podía aplicar a los equipos ágiles.
Finalmente, abriendo un poco más nuestra mente y sin centrarnos en los típicos pensamientos de “esto es un juego, hay un vendedor y un cliente”, y más en el papel de Paul en la dinámica, en el comportamiento de los voluntarios, en su forma de responder, en el contexto y las restricciones del juego (por ejemplo, no poder decir la letra S), nos asombramos de cómo ciertas cosas que habían salido en la dinámica son aspectos o problemas que aparecen en los equipos ágiles (o cualquier equipo en general):
– No decir la letra ‘S’ es una restricción impuesta, de fuera.
– Cuando si alguien dice la letra S consideramos que falla, y tiene que cambiarse por otra persona nueva, la gente va con miedo a hacer el ridículo, habla más despacio, se enfada consigo misma cuando falla y se frustra. Las conversaciones son más sencillas, dentro de un terreno conocido y menos creativas.
– Cuando Paul cambió el foco de la dinámica y en vez de promover el miedo al fallo, dijo que el foco de las personas que hablaban debía ser tener conversaciones entretenidas, buenas, para divertir al público (el público consideraba si la conversación era buena o no silbando si no le gustaba), la gente estaba más relajada, las conversaciones fueron mejor y los participantes se divertían más.
La restricción de no decir la letra S seguía presente, pero un único fallo al hablar no era motivo de represión, sino de aprendizaje. Lo importante en general era hacer las cosas bien y rápido.
– Para mí esta dinámica demostró las diferencias entre poner el foco de un equipo en la represión, la recriminación y la culpa ante un fallo (1er caso), frente a poner el foco en hacer las cosas bien, con calidad. Para mí, queda claro que haciendo por primera vez esta actividad todos cometeremos fallos, ya que somos personas haciendo por primera vez algo a lo que no estamos acostumbrados.
La diferencia está en si permitimos la creatividad, el aprender de nuestros errores, o lo importante es el hecho de que alguien ha fallado.
Los resultados de promover un entorno donde prime una cosa u otra fueron muy visibles en la actividad. Y hay muestras de esto todos los días en los equipos, con sus managers, jefes, compañeros, etc.
Por ello, seguro que llevaré a cabo esta actividad para que la gente se dé cuenta en sus propias carnes de las consecuencias del entorno que se promueve en los equipos de trabajo 🙂
Para mí fue una charla muy inspiradora, porque aunque hay ciertas cosas que ya sabemos, como el fomentar un entorno donde se pueda fallar (controlado), para mí muchas veces es complicado hacer ver a otras personas los beneficios de promover ese tipo de cosas. Y la charla de Paul me llenó de ideas para intentar transmitir esos temas de forma sencilla, y haciendo que la gente lo experimente, reflexione y saque sus conclusiones.
Improving Agile Teams
Para quien quiera profundizar en este tema, Paul ha escrito un libro llamado Improving Agile Teams – Using constraints to unlock creativity, donde amplía estos temas y explica más técnicas de improvisación que podemos utilizar en el día a día de los equipos ágiles. Nada más salir de su charla, no dudé en comprarme el libro en la librería de la conferencia, y no me arrepiento de ello: es muy inspirador y centrado en las personas.
Por ejemplo, volviendo a la actividad de las ‘S’ que mencioné antes, Paul comenta que podría utilizarse para que dentro de un propio equipo la gente se relaje, se elimine el miedo a cometer errores y a “hacer el ridículo” entre los compañeros del equipo al fallar. Para ello podríamos hacer que un daily meeting tenga que llevarse a cabo sin poder decir una letra determinada.
Terminando…
Tras leerme el libro, creo que este tipo técnicas se pueden aplicar los equipos ágiles, porque para mí un equipo ágil se parece en ciertos aspectos a un grupo de improvisación teatral (en términos de personas, equipo, no en cuanto a restricciones técnicas o necesidades de negocio).
Por ejemplo, justo al inicio del libro, Paul hace referencia a lo importante que es la seguridad en un equipo de improvisación. Estos equipos se enfrentan a una incertidumbre total, ya que cada obra es diferente, no tienen un guión, nada que les diga qué tienen que hacer y cómo deben responder en cada momento.
El primer sentimiento ante una situación de incertidumbre es miedo. ¿Pero cuál es entonces una de las claves del éxito de estos equipos de improvisación? La seguridad. Los mejores resultados se dan cuando los miembros del equipo se sienten confiados y seguros con sus compañeros. Cuando los actores se sienten inseguros, se paralizan, fallan más y los resultados son peores. Cuando las personas se sienten seguras y confían en los demás, el objetivo final es hacer las cosas bien como equipo, no hay esas faltas de comunicación que generan errores y las debilidades de unos compañeros se suplen con las fortalezas de otros.
Si ahora lees estos últimos párrafos pensando en un equipo ágil o un equipo software, ¿te cuadra igual? A mí desde luego que sí.
Para mí esto es un ejemplo más de cómo la agilidad cuadra con otras disciplinas y cómo el mundo del software puede beneficiarse de técnicas o de formas de trabajo de otras áreas.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Muy bueno, precisamente estaba escribiendo un post sobre la literatura y la agilidad. Hay que cambiar las metáforas!