Tiempo de lectura: 7 minutos
  • Se abre el telón y se ve a Elon Musk, al Señor Cangrejo y al asistente de Schrödinger entrando a una sala. Se cierra el telón.
  • ¿Cómo se llama la película?
  • Las mil y una meetings de Scrum.

¿Qué? ¿No me crees? No te culpo, pero creo que puedo convencerte un poco tras leer este post.

Bromas aparte, tras unos años de experiencia trabajando con Scrum y asistiendo a muchas de las reuniones que tiene, he sacado una serie de conclusiones/reflexiones que me gustaría compartir (y sí, tienen que ver con Elon Musk, el Señor Cangrejo y Schrödinger).

Pero antes que nada, por si alguien no las conoce, dejo por aquí esta tabla resumen con las principales:

Reunión Duración aproximada Asistentes Cuándo se hace Para qué sirve
Sprint Planning 4h máx. (**) Todo el equipo de Scrum Al inicio del Sprint Se decide qué tickets del Product Backlog van a entrar en el Sprint.
Daily Scrum o Stand-up ~15min Todo el equipo de Scrum Diariamente al comienzo de la jornada Para poner al equipo al día, todos exponen muy brevemente lo que hicieron el día anterior, lo que van a hacer en la jornada actual y si tienen algún bloqueo.
3 amigos ~30-45 min BA, QA y DEV (*) Durante el Sprint Los implicados en el desarrollo de un ticket se reúnen con la finalidad de aclarar dudas y poner en común posibles escenarios desde todos los puntos de vista (negocio, calidad y desarrollo).
Sprint Review 2h máx. (**) Todo el equipo de Scrum Al final del Sprint Consiste en enseñar una demo de lo que se ha desarrollado durante el Sprint a todos (otros equipos de Scrum, el Product Owner, etc.), para que estén al día del avance del proyecto.
Sprint Retrospective 1.5h máx. (**) Todo el equipo de Scrum Al final del Sprint La reflexión del final de Sprint, donde se discute sobre lo que ha ido bien, lo que ha ido mal y las acciones a tomar para evitar que lo que ha ido mal se siga repitiendo. A veces se hace junto a la Sprint Review, al inicio de la misma.
Product Backlog Refinement 1.5h máx. (**) Todo el equipo de Scrum Al final del Sprint Es como un paso previo al Sprint Planning. Cuando se va acercando el final del Sprint actual, puedes ir haciendo una previsión de lo que irá al siguiente Sprint. Si se hace esta reunión, normalmente luego la reunión del Sprint Planning es mucho más corta.

(*) BA: Business Analyst, QA: Quality Assurance, DEV: Developer

(**) Para Sprints de 2 semanas de duración

 

– Eh, tenemos meeting en 5 min, en la sala Princess Consuela BananaHammock, tú vienes, ¿no?

– 

 

Hay que ir con los deberes hechos

Ir a la reunión improvisando no suele ser la mejor idea. Para todas, en mayor o menor medida, hay que dedicar tiempo previo.

Desde una simple Daily (donde, si tienes muy buena memoria, no necesitarás más que 1 minuto y en el peor de los casos 5 minutos), cuando llegas al trabajo y arrancas, echas un vistazo a lo que hiciste el día anterior para ver por dónde continuar hoy y te planificas el día. Justo ahí, si te haces una pequeña lista mental, ya lo tienes todo para la Daily.

Está claro que la cosa se puede complicar mucho más e ir bastante más allá de 5 minutos…

  • Para el Sprint Planning, deberías haber echado antes un vistazo al Product Backlog, para ir con propuestas propias y que los tickets no te suenen a chino cuando se hable de ellos.
  • Para la Retrospective, ir con tus propias propuestas ya pensadas en lugar de hacerlo durante la propia reunión (ya que seguramente no serás capaz de pensar más que en los puntos que han sugerido ya el resto de compañeros).
  • Para la 3amigos meeting hay que ir con los deberes muy muy hechos: si eres el desarrollador, pensar a qué puede afectar el código que vas a desarrollar; si eres el QA, llevar una propuesta de Test Plan; si eres el BA, tener muy claro el punto de vista de negocio para resolver todas las dudas.

En general, prepararte un poco de qué va a ir el tema, para que no te pierdas en la reunión y no hacer perder el tiempo de otros que sí se lo han preparado (no es más que sentido común).

Esto no quiere decir que no puedas preguntar nada, ¡en absoluto! (muchas de ellas, de hecho, consisten en preguntar). Pero una cosa es preguntar cuál es el comportamiento esperado de un botón porque no queda claro en el ticket, o incluso el color por muy tonto que parezca, por ejemplo; y otra muy diferente es enterarte en la reunión de que había un botón.


To be, or not to be
, that is the question

Pero esta vez to be de estar, más que de ser. Y no estar de cuerpo presente, sino de mente (y cuerdo, a ser posible).

“En el término medio está la virtud” dijo Aristóteles. Y no puedo estar más de acuerdo pero, ¿qué sería de este maravilloso mundo sin excepciones que confirmen las reglas? En mi opinión, cuando de reuniones se trata, no hay términos medios, sólo dos opciones: o vas, o no vas. Así que, aun siendo más fan de Aristóteles que del maestro Yoda, esta vez estoy con éste último… “Hazlo, o no lo hagas, pero no lo intentes”.

El multitasking está muy bien, pero creo que no siempre es válido.

Si vas a una reunión donde hay una persona hablando y tú estás con el ordenador, educación aparte (ya que es un poquito falta de respeto hacia quienes hablan), realmente deberías preguntarte, por ti y por todos los asistentes, ¿para qué vas? ¿qué esperas de esa reunión? ¿esperas aportar algo? ¿esperas enterarte de algo?

Responder a correos, gestionar al equipo, mirar los updates de Jira, y en general cualquier cosa que no tenga que ver con la reunión no es algo que debas hacer durante la misma. Carpe diem my friend: si estás en la reunión, estás en la reunión, y estás escuchando a quien habla y aportando lo que tengas que aportar. En definitiva, evita a toda costa ser el asistente de Schrödinger(*).

Si tienes otra prioridad, es perfectamente válido, hazla y no vayas a la reunión.

Si es vital que tú estés presente, intenta posponerla.

(*) Aquella persona que en el mismo instante está y no está en la reunión

 

El tiempo es oro

Y no lo digo yo, ¡lo dice el Señor Cangrejo!

Los tiempos de duración de las reuniones en la tabla son orientativos, y agile aboga por la flexibilidad y la adaptación; sí, PERO tampoco hay que abusar. Que te pases en alguna Daily no es el fin del mundo, pero que todas las Dailys duren 30 minutos o una hora no es lo más óptimo.

En el caso de las reuniones, la expresión “el tiempo es oro” se vuelve literal, y podemos comprobarlo con esta calculadora.

Normalmente, cuando empiezas a pasarte del tiempo con cierta frecuencia, suele tener una causa. Las más comunes que he visto:

  • Desvío del foco: empezar a hablar de cosas que no tienen nada que ver, ya sean temas personales o profesionales, pero no relacionados con el objetivo de la reunión. Te puedes desviar un poco, y preguntar un lunes qué tal el finde, pero tampoco es plan de llevarte 20 minutos hablando de eso, puedes hacerlo en el desayuno.
  • Atascos técnicos: por llamarlo de algún modo, esto suele pasar en las Dailys o en las 3 amigos. Profundizar demasiado en una duda o un atasco, desviándote por completo de la reunión e invirtiendo la mayor parte del tiempo de la misma en resolverlo.

¿Soluciones? A falta de un Scrum Master, que alguien se encargue de que los tiempos más o menos se cumplan y no se pierda el foco de la reunión. Si alguien empieza a desviarse demasiado, reencaminar el objetivo de la reunión. Si se empieza a dar demasiadas vueltas a un asunto, parar, retomar el foco de la reunión actual y convocar otra con las personas que realmente están involucradas en el atasco/problema/whatever.

 

¿Son todas necesarias realmente?

Aunque la respuesta es muy obvia, la realidad no siempre lo refleja.

Creo que no son todas necesarias, y aun así, a veces se fuerzan. Las reuniones cuestan dinero, como acabamos de ver, y tienen un propósito. Si no lo van a cumplir, ¿para qué convocarlas? Algunos ejemplos que se me vienen a la mente:

  • Si el ticket está clarísimo, es muy muy obvio, todos los implicados saben qué tienen que hacer, ¿tiene sentido convocar una 3 amigos meeting? ¿invertir tiempo y energía en buscar un horario que cuadre a BA, QA y DEV? En mi opinión, no lo tiene.
  • Si en el Sprint actual vas mal de tiempo, no vas a ganar “adelantando” el Sprint Planning convocando un “Product Backlog Refinement”, de hecho en vez de/a costa de adelantar el siguiente, muy probablemente vas a atrasar el actual.

Bonus track

También puede ser que convocases la reunión porque pensabas que iba a ser necesaria, pero resulta que no está siendo para nada productiva… bien, pues en este caso, nuestro querido amigo Elon Musk dice que ¡nos vayamos!

Entre sus consejos de productividad relacionados con este tema, dijo:

  • Cancela las reuniones largas, y si tienes que tenerlas, hazlas “muy breves”.
  • Vete de una reunión o cuelga una llamada si no está cumpliendo su objetivo.
  • Ignora estas reglas cuando seguirlas sea obviamente ridículo.

Y aunque me gustan sus tips y me parecen sensatos, creo que se puede dar el caso de situaciones en que la línea que separa la educación de la productividad sea tan tan tan fina que sea demasiado peligroso cruzarla.

Aun así, alguna vez merece la pena el riesgo por no perder 4 o 5 horas de tu vida en reuniones de mierda interminablemente poco provechosas.

 

Conclusiones

  • Convoca la reunión sólo si tiene sentido, si aporta valor.
  • Prepara la reunión antes de asistir.
  • Ve sólo si de verdad vas a estar.
  • Intenta ceñirte a los tiempos y objetivos de la reunión.

Y todo esto, ¡hazlo por ti, por todos tus compañeros y por ti primero! 😊

Verónica Ojeda

Software Developer @ Gloin - También intento ver todas las series que me recomiendan, leo millones de artículos (desde tecnología, hasta recetas semisanas, pasando por muchos DIY), y por último, pero no menos importante, viajo más de lo que puedo y menos de lo que debo.