Era un viernes cualquiera, más o menos a la 1 del mediodía. Estaba yo facilitando la retrospectiva de fin de sprint. El ambiente era distendido y se notaba ya la brisa del fin de semana. Estaban todos los miembros del equipo añadiendo las tarjetas virtuales de aquellas actividades que querían hacer más, hacer menos, dejar de hacer, empezar a hacer y continuar haciendo. Vamos, el Starfish de toda la vida.
Entonces ocurrió. Sí, otra vez. Un miembro del equipo había puesto una tarjeta en «Hacer menos» indicando que había que hacer menos reuniones porque «estando en reuniones no puedo trabajar«. OMG!.

Es muy posible que esto no sea nuevo para tí. Para un equipo que está intentando trabajar con Scrum, una de las mayores fricciones que puede haber es el ver los rituales de Scrum (dailyes, planning, review, retro y refinamientos) como un impedimento para estar más horas picando código. Y el argumento suele ser el mismo. «Las reuniones nos quitan eficiencia».

Las primeras preguntas que deberían surgir cuando alguien habla de eficiencia son las que me ha recordado Angel Medinilla en su tweet. : ¿Qué es para tí la eficiencia? ¿En base a qué la mides, qué métrica? y la que quizá es más importante: «¿Qué dejas de lado para conseguir esa eficiencia?

Por otro lado, en mi opinión, esta actitud forma parte de los remanentes de una cultura en la que el desarrollador sólo aportaba valor convirtiendo unas especificaciones a bajo nivel en código de programación. Mero «fagocitador de backlog» que su atención pasa de la tarea que tiene asignada en JIRA o sistema de gestíon de tareas similar, al Pull Request que hace para darlo por terminado. Nada más ni nada menos. El tipo de programador al que se le puede decir: «Programador, dame cuarto y mitad de código en Java». Su rendimiento unicamente se basa en la cantidad de código que produce.

Sin embargo y por suerte, cada vez queda más extendida la idea de que el desarrollo de software es una actividad social. No se puede pretender ser buen desarrollador y no hablar con negocio para entender de primera mano qué necesitan, sin hablar con otros compañeros como QA, diseñadores, expertos en BBDD etc.. si quieres asegurarte que aquello que estas haciendo encaja como un anillo en lo que ellos están haciendo.
¡¡ No puedes !!

Si eres de los que creen que para tí no son las reuniones, hazte la pregunta de qué es para tí trabajar y por qué esa definición no la ves en las reuniones a las cuales te invitan. Quizá te estás perdiendo una parte importante de tu trabajo, y personalmente para mi, muy motivadora. Y posiblemente sea porque nadie te ha explicado todo lo que implica el desarrollo de software. Quizá sólo estás viendo tu trabajo desde un agujerito en el que el escribir líneas de código es tu único propósito. E incluso, sí, ¿por qué no?, quizá eso lo único que quieras hacer. Y lo puedo respetar. Pero si es así, te recomiendo expresarlo claramente a tu equipo para que no se hagan faltas expectativas. Es posible que no piensen como tú.

También he visto que este problema ocurre de arriba a abajo en jerarquía. Puede verse como algo normal la actitud de no incluir a todo o parte del equipo en reuniones para que «no pierdan el tiempo ya que hay prisa en las entregas». Esto es un síntoma más de un liderago de tipo paternalista en el que se impide el crecimiento y maduración de los «niños» «por su propio bien». En fin…

Cada miembro del equipo debería ser capaz de elegir cómo usar su tiempo de forma más eficiente para aportar el máximo valor como profesional. Si es asistiendo a las reuniones de negocio para entenderlo mejor y evitar errores, que así sea. Si es juntandose con todos los implicados en una historia de usuario, para sincronizaros y comprobar que teneis la misma visión, que así sea. Si eres manager de un equipo, intenta no decidir por cada uno de ellos cómo gestionar su tiempo para ser buen desarrollador. Esta decisión es muy importante, compleja y personal.

Los miembros del equipo deberian entender qué valor da y qué propósito tiene cada tipo de reunion, qué aporta. El valor, aparte de la sincronización del equipo o tener conocimiento de producto, también podría ser el poder decidir en una retro cómo mejorar, e incluso podría ser el escuchar de primera mano del CEO de la empresa que «vamos bien», o «vamos mal» y saber que estamos todos en el mismo barco. Como manager lo que sí que puedes hacer es asegurarte que esto lo tengan muy claro para que puedan tomar sus propias decisiones.

Disclaimer: Todo lo escrito arriba no está en conflicto con hacer un uso inteligente de las reuniones e intentar hacer cada uno de la forma más efectiva y eficiente. Para esto hay miles de consejos y técnicas como el que haya un facilitador, tener agenda, centrarse en el objetivo de la reunión, etc.. E incluso, si hay reuniones que no aportan valor a nadie, naturalmente lo mejor es eliminarlas.