miércoles, 29 de agosto de 2012

El Poder de la Escucha Profunda


El domingo 28 de agosto se realizó el Agile Open Lima VI en la Universidad Peruana Unión. Tuve la oportunidad de co-facilitar un par de sesiones y facilitar otra más en solitario. Decidí llamarla "El poder de la escucha profunda para la colaboración e innovación en equipo." Esta es la descripción que coloqué en el site de UserVoice del evento:

Muchas veces se supone que 'saber escuchar' es una capacidad con la algunos pocos han sido bendecidos y la mayoría de nosotros no. Es más, no somos conscientes de nuestra propia capacidad de escucha y del efecto que ésta tiene en nuestro quehacer personal y profesional. Menos aún nos enseñan en el colegio, o en la educación superior, cómo afinar nuestras habilidades de escucha.

Sin embargo, está plenamente demostrado que una capacidad de 'escucha profunda' o activa es una de las bases imprescindibles para construir equipos de alto rendimiento, colaborativos e innovadores.

En este taller exploraremos, a través de juegos y dinámicas, cómo mejorar nuestras habilidades de escucha y concentración para elevar nuestra capacidad de trabajo en equipo.

Para estructurar la sesión, me basé sobretodo en parte del excelente taller que llevé el año 2010 con Lee Devin sobre Artful Making. También empleé algunos ejercicios que facilita Alan Cyment como parte de sus los cursos Certified Scrum Master que dicta y en esta actividad grupal de David Koontz.

La estructura fue más o menos la siguiente:
  1. Ejercicio básico de construcción colectiva/improvisación: Construcción de una historia corta para que los participantes experimenten con su capacidad de escucha actual.
  2. Ejercicio de escucha inefectiva: Para que los asistentes constanten qué se siente cuando no nos escuchan.
  3. Explicación y ejercicios con la técnica F-W-R (Focus-Wander-Return): Para aprender esta técnica básica de concentración que nos permite mejorar sustancialmente nuestras habilidad de escucha activa.
  4. Nuevamente se repite el primer ejercicio para que los participantes comprueben si existió una mejora tras lo aprendido en el punto 3.
  5. Conversatorio abierto sobre lo aprendido en el taller y los beneficios que pueden obtener aplicando estas técnicas en los respectivos entornos profesionales de cada uno. La conversación se llevó a cabo usando The 5 Second Rule
Aquí comparto algunas fotos:



Me dio gusto recibir el buen feedback de los asistentes y comprobar que en la retrospectiva al final del evento la gente dio también una evaluación positiva.

Si les interesa que facilite este taller gratuitamente en sus organizaciones, pueden contactarme al mail del blog o por cualquier otro canal.

jueves, 21 de junio de 2012

El extraño Mundo de Agile


Imagina que toda tu vida has habitado mundo oscuro y sombrío poblado por bichos feos, monstruos, brujas, esqueletos y fantasmas. Y que todas las actividades que realizas se consideran exitosas si logran el tan ansiado fin de asustar a las personas.

Y ahora imagina que por casualidad descubres un mundo diferente, lleno de de luces, colores, sonrisas y felicidad por todos lados. Al ver esta realidad totalmente distinta no puedes evitar sentirte atraído y enganchado a todas estas nuevas sensaciones, así que decides llevar estas cosas maravillosas a tu lugar de origen y convencer a todo el mundo de hacer las cosas tal y como las has visto en aquel mágico paraje.

Pues bien, esto es precisamente lo que ocurre en la película El extraño Mundo de Jack (The Nightmare before Christmas) donde el protagonista, Jack Skellington, cansado de celebrar Halloween año tras año, descubre la Navidad, queda fascinando por ella, y decide tomar control de la misma junto con sus amigos.

Ahora, Jack no es un personaje malvado ni un mal tipo. Todo lo contrario, tiene la mejor intención del mundo. El problema es que ni él, y mucho menos sus amigos, comprenden realmente el significado de la Navidad. Sólo se concentran en replicar lo que aparentemente ven que funciona sin reparar en los sentimientos, actitudes y motivaciones detrás.

Es así que terminamos con juguetes que asustan a los niños, esqueletos de renos vueltos a la vida, trineos en forma de ataúd un esqueleto volador haciéndola de Santa Claus, a quien Jack llama Santa Atroz (Sandy Claws) pues es el nombre que cree escuchar durante su visita a la tierra de la Navidad.

¿A qué va todo esto? Pues a que últimamente he estado observando que mucha gente se comporta precisamente como Jack cuando descubre los Métodos Ágiles, ya sea mediante un curso, libro, artículo o evento de la comunidad. Quedan deslumbrados por la simpleza y efectividad de prácticas tales como el uso de un Panel de Tareas o la realización de Reuniones Diarias de 15 minutos, así que deciden llevar estas técnicas a su contexto diario copiando tal cual lo que observaron, pero sin entender los principios y valores detrás, conviertiéndose en practicantes de Cargo Cult Software EngineeringEs así que el entusiasmo dura algunos pocos días, tras lo cual se vuelve a lo mismo de siempre. 

En otros casos, las prácticas se modifican de manera poco juiciosa ("¡Hagamos la reunión semanal en lugar de diaria!", "¡En lugar de panel altamente visible para el todo el equipo, tengamos uno pequeño que sólo el Project Manager ve!") para volverlas más acorde al status quo imperante, con lo que éstas pierden fuerza, impacto y éxito.

¿Que tan extendido está este fenómeno? Al parecer es lo que ocurre en la mayoría de organizaciones que implementan Métodos Ágiles, según este reciente estudio de Forrester. ¿Es algo inevitable a largo plazo? Quizás sí lo sea. Tal vez sea un ejemplo más de la evolución del conocimiento, entendido como el patrón dialéctico de tesis, antítesis y síntesis, tal como explica aquí Juan Palacio. Quizás también sea la consecuencia de la creciente popularidad que vienen alcanzando métodos como Scrum, demostrando una vez más la Ley de la Mermelada de Frambuesa.

¿Han observado esta situación en sus organizaciones? ¿Les parece el camino a seguir?

viernes, 30 de setiembre de 2011

La Invasión de los Gerentes de Proyecto


Hace unos días me junté con un viejo amigo, a quien no veía hacía un buen tiempo; llamémoslo Luchín. Mi amigo trabaja hace ya unos 4 años como desarrollador senior en una empresa local proveedora de soluciones de software. Muy acongojado, Luchín me contó: "Ahora sí que se fue todo al diablo. Llegó la invasión de los gerentes de proyecto a la empresa". Mi primera reacción fue de decepción, pues durante 3 años trabajé en esa empresa y me esforcé por forjar una cultura que cultive precisamente lo contrario a lo que esa frase vaticinaba.

Esta situación coincidió con un thread muy activo a inicios de este mes en la lista de la comunidad Agile Perú, el cual fue abierto con una cita extraída de un tweet del mundo real"Ya no quiero ser ingeniero, quiero ser gerente de proyectos!" El thread creció muy rápidamente hasta llegar a tener más de 60 replies en menos de dos días. Es evidentemente un tema sensible, un tanto polémico y que está "de moda".

¿Pero, de qué estoy hablando exactamente? Vamos al grano. Tomaré como definición general de gerente de proyectos a alguien que:
  • Ya no desarrolla software
  • Les dice qué hacer a los desarrolladores
  • Es pagado considerablemente mejor que a los desarolladores
  • Es visto con mejores ojos y tiene más status que los desarrolladores ante todo el personal
  • No es explotado ni forzado a trabajar horas insanas
  • Tiene el privilegio de repartir tarjetas de presentación y firmar e-mails que dicen "Gerente"

¿Y cuál es problema con todo esto?

Bueno, desde mi humilde punto de vista, veo lo mismo que Tobias Mayer describió muy claramente hace ya 2 años en esta serie de iluminadores artículos:

Extraigo algunas secciones imperdibles:

The tragedy of many revolutions is that once successful the leaders tend towards the same behavior that caused the need for the revolution in the first place. The oppressed become the oppressors, i.e. they take on essentially the same behaviors because they don’t know how else to behave.
George Orwell characterized this tendency in the novel Animal Farm, an allegory for the Russian Revolution and subsequent events.  By the end of the book, the revolutionary leader, Napoleon (a pig, by some charming coincidence) is walking on two legs, dressing in human clothing and selling his best friends out for horse meat.

There can be no really pervasive system of oppression . . . without the consent of the oppressed.” —Florynce Kennedy
Too often the oppressed don’t want change; they simply want to be on the other side of the oppression.  That is the ugly reality we live in.  We have all seen individuals rise to middle-management and change behavior accordingly, fitting in to the system and emulating their superiors.  Many of us have seen teams fall apart through infighting — indeed a key part of the Scrum Master training course is focused on dealing with such situations. Reward systems in most software corporations are based on individual superiority, and to be superior, others must be considered inferior.
Commenting on the syndrome of in-fighting between oppressed natives in colonized countries, Paulo Friere notes “At a certain point in their existential experience the oppressed feel an irresistible attraction towards the oppressors and their way of life.  Sharing this way of life becomes an overpowering aspiration.  In their alienation, the oppressed want at any cost to resemble the oppressors, to imitate them, to follow them.”

En resumen, esto significaría que muchos desarrolladores al hartarse de la opresión a la que son sometidos por sus respectivos jefes o gerentes de proyecto, no ven otra salida que convertirse en opresores ellos mismos y a perpetuar (probablemente de forma inconsciente) el mismo modelo de opresión antes nuevos desarrolladores.

Esta opresión se expresa comúnmente a través del lenguaje de los opresores, con frases del tipo: "No sé que haces pero lo quiero para mañana".

Lo paradójico de todo esto, al menos en mi caso, fue que hace poco tuve que firmar un mail con el título de Gerente de Proyectos. No precisamente por una preferencía mía, sino del cliente con el que estaba trabajando, quien a su vez deseaba proyectar cierta imagen ante su respectivo cliente.

Y ustedes, ¿qué quieren ser cuando "crezcan"?