¿Cuántas veces ha terminado una larga reunión con la sensación que fue completamente inútil?

Estoy seguro que ha perdido la cuenta y que odia cada vez que lo llaman a reunión: desconcentración de lo que estaba haciendo y aburrimiento.

Scrum establece muy pocas ceremonias: Sprint Planning, Daily Scrum (o Daily Stand-up más adelante veremos por qué estar de pie es vital que sea efectiva), Sprint Review y Sprint Retrospective. El Scrum Master se encarga que estas reuniones sean facilitadas. Si estas ceremonias no son ejecutadas efectivamente de la forma más eficaz, el equipo va hacia la deriva y a aumentar considerablemente los costos de operación.

Debido a que esta es una enfermad ("Reunionitis") generalizada en las organizaciones donde se desarrolla software, compartiré con usted algunos fuertes consejos que me han sido útiles.

Pongámonos serios con respecto a nuestro problema con las reuniones

En alguna oportunidad Seth Godin en un artículo que ya no está online había hablado sobre tomarnos en serio el problema que tenemos con las reuniones mediante los siguientes recomendaciones (con algunos comentarios míos):

• Si todos los problemas no son iguales, ¿por qué todas sus reuniones son iguales? ¿Cada problema merece una hora? ¿Por qué hay una extensión de tiempo por omisión?
• Exija preparación. Dele a las personas cosas para leer o hacer antes de la reunión, si ellos no lo hacen, sáquelos de la reunión.
• Remueva todas las sillas de la sala de conferencias. Hablo en serio. [Los Daily Scrums se hacen de pie con el intención explícita de tener una posición corporal que fatigue, de manera que a los quince minutos de haber empezado la reunión los participantes estén cansados. Los Daily Scrums nunca deben durar más de quince minutos.]
• Si hay alguien llega diez minutos tarde que la última persona en llegar, tendrá que pagar una multa de diez dólares a ser depositado el “Fondo para el Café” [es un fondo creado por el equipo para comprar snacks y café].
• Lleve un Egg timer a la reunión (yo siempre llevo conmigo mi “Cubo del Tiempo”). Cuando se acaba el tiempo en el timer, la reunión se acabo, no es su culpa, es culpa del timer (no tienen idea cuán poderoso es este concepto).
• El organizador de la reunión debe enviar un corto e-mail de resumen con puntos de acción (acciones a tomar) a todos los participantes después de diez minutos de haber terminado la reunión.
• Cree un espacio público (una pizarra, o un pedazo de poster grande, o hasta una pagina web) donde permita calificar las reuniones en una escala de 1 a 5 (se refiere a usar una escala psicométrica de Likert de 1 a 5, aunque yo prefiero la escala de 1 a 7 pues hace a las personas a pensar mucho más el criterio de evaluación que las escalas de 1-5 o 1-10) en términos de cuán útil fue la reunión. Una simple caja en donde cualquiera puede escribir un número. Observe lo que ocurre.
• Si usted no está aportando ningún valor a la reunión, váyase. Siempre puede leer el resumen después.

Adicional a estos consejos, agrego unos cuanto más:

• Haga explícito cuánto dinero está costando la reunión. Sume todos las fracciones de salario por unidad de tiempo de los participantes y hágalo saber a los participantes: “Esta reunión tiene un costo de X por hora”.
• Sin ningún temor abandone la sala de conferencias cuando ha transcurrido una hora y la reunión ha sido inefectiva.
• No espere a su jefe. Hay muchos jefes irresponsables que piensan que el mundo gira alrededor de ellos. En Costa Rica he notado una relación directamente proporcional entre la altura del puesto organizacional que una persona tiene y la cantidad de tiempo que esa persona llega tarde a una reunión. Si su jefe no ha llegado y todos llegaron a tiempo, empiece la reunión.
• Al iniciar la reunión repase los asuntos que efectiva y realistamente se pueden resolver durante la reunión.
• Al definir Puntos de Acción, recordar que cada Punto tiene asociado una persona responsable de ejecutarlo y métricas asociadas para determinar que efectivamente fue ejecutado y que cuya ejecución solucionó el problema en cuestión.
• Al terminar la reunión,  repase todos los argumentos alcanzados, los puntos de acción las personas responsables de ejecutar cada punto de acción.

No interrumpa el flujo mental de los programadores

El último consejo tiene que ver con respetar el flujo mental de los desarrolladores de software. El libro Peopleware documenta este estado mental:
"El flujo es una condición de profundo y casi meditativo involucramiento. En este estado, hay un suave sentido de euforia y uno pierde control del paso del tiempo [...] No hay conciencia de esfuerzo, el trabajo parece solo, bueno, fluir [...]"

En este estado es cuando todo el trabajo productivo se hace. Para entrar en este estado, un desarrollador necesita cierta cantidad de tiempo, una vez allí, cualquier interrupción saca a la persona inmediatamente del "flujo", o de la "Zona" como también se le conoce.

Dicho esto, piense dos veces si vale la pena interrumpir a un desarrollador para una reunión (que al final no cuenta como trabajo productivo, si no como gasto operativo). Y si  definitivamente es necesario, trate de hacer la reunión en alguno de los siguientes momentos: al inicio del día, antes de la hora de almuerzo, después de almuerzo o al final del día.

Artículos recomendados:

• Meetings Are a Matter of Precious Time.
• Meetings and More Meetings: The Relationship Between Meeting Load and the Daily Well-Being of Employees [PDF]