¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.techbiz
Gabriel Salafranca 21/05/2018 Cargando comentarios…
“Tenemos muchas reuniones”, fue la reflexión concisa y categórica de uno de mis compañeros de oficina. Muchas reuniones, demasiadas. Y la verdad es que estoy de acuerdo con él. Además muchas veces no se celebran con un objetivo claro y con errores de ejecución comunes que las hacen, en general, improductivas.
Siendo más conciso aún, mi compañero especificaba: “en Scrum hay muchas reuniones”. Y ahí, en ese punto en concreto, no podía estar de acuerdo con él. ¿Pero por qué? Pues bien, ha llegado el momento de justificarlo.
En mi experiencia, esta idea principalmente tiene su origen en los siguientes problemas :
La formación en Scrum no se puede quedar en una charla introductoria cuando un trabajador se incorpora a la empresa. Durante las primeras semanas/meses le debe quedar claro qué es y qué no es Scrum, y además evitar que los conceptos se difuminen poco a poco o se vayan confundiendo con el paso del tiempo.
Esto en Paradigma lo tenemos muy interiorizado y muy presente en nuestro día a día. De manera periódica refrescamos conceptos a los equipos mediante nuevas formaciones y acceso a certificaciones, intentamos hacer comunidad de buenas prácticas también en el ámbito de Agile y somos bastante accesibles a la hora de resolver dudas.
El segundo de ellos es que determinados roles de cierta relevancia en los equipos (como Scrum Master o Product Owner) traen consigo un popurrí de ideas con todo esto de “lo Agile”. Esto supone que se fomenten prácticas en nombre de Scrum y que no son Scrum. De esta manera confundimos a la gente.
Por ejemplo, me han hablado de daily meetings de 45 minutos de duración (esperemos que no sean de pie). O de reviews que son directamente “demo a los clientes”, donde no interviene el Product Owner para nada.
He leído también algún artículo que propone hacer encuentros de micro-retrospectivas de manera diaria, llegando ya al colmo de la reunionitis.
Otros casos como el refinamiento del producto con todo el equipo para que realice una estimación de todo lo hablado. Todas ellas son malas prácticas y ante la observación de ello, los Scrum Masters (convenientemente formados) deberían actuar como agentes de cambio.
Esto por ejemplo me ha ocurrido con los comités de la alta dirección (steering committee). Como los eventos de Scrum están agendados de una manera algo rígida, la alta dirección, a pesar de estar invitada, no suele asistir.
Por eso creamos estos comités, por la falta de presencia de esta capa en el día a día del producto. No estoy diciendo que no se deban realizar, ya que evidentemente resuelven esta problemática, pero no sacamos todo el partido a la Sprint Review.
Lo mismo ocurre con reuniones semanales de seguimiento que son pseudo-plannings y cuasi-reviews.
Es cierto, en numerosas ocasiones no usamos los eventos de Scrum para innovar y para hacer un ejercicio de inspección y adaptación y eso hace que los propios equipos tengan una visión un tanto negativa de las mismas.
Nos pasa con Sprint Planning aburridas y eternas, o Daily meetings repetitivas en las que no se mira el objetivo del Sprint. Son ejemplos de baja productividad.
Con todo y con eso, parece que siguen pareciendo demasiadas. Pensemos por un momento qué evento quitaríamos si Jeff y Ken (creadores de Scrum) nos diesen permiso para eliminarlo.
¿La planning? ¿Y lo dejamos todo al libre albedrío y al buen hacer del equipo de desarrollo, que no se ha reunido en ningún momento para que nadie le explique qué debe desarrollar?
¿La review? ¿Y quitar la oportunidad de ver a los interesados y compartir con ellos el avance del último periodo y hacer proyecciones futuras?
¿La retro? ¿Quitamos entonces un momento fundamental para que el equipo se encuentre, con el único fin de revisar su proceso y mejorar?
¿La daily meeting? ¿De verdad que no puedes dedicar 15 minutos al día a ver cómo estamos en este Sprint y contar los posibles impedimentos?
Nota: Por cierto, las reuniones de refinamiento no son un evento de Scrum, sino un medio que algunos hemos encontrado valioso para refinar el producto y que no debe superar un 10% la capacidad del equipo de Desarrollo.
Se me antoja muy complicado quitar cualquier evento de Scrum porque todos tienen un gran valor.
Hoy en día las empresas arrastran una cultura de reuniones muy arraigada. Quizá el primer paso, además de reducir y simplificar los encuentros, es sacar más provecho de los mismos.
He hecho un pequeño inventario de algunos trucos para que tus reuniones sean más efectivas:
Antes de convocar, plantéate: ¿debe realizarse? A mí me abrió los ojos esta página de los amigos de Atlassian, donde recogen que en EEUU se gastan en torno a 37.000 millones de dólares en reuniones. ¿Reflexionamos en nuestras empresas sobre lo que cuesta una reunión improductiva?
A veces pensamos que de una reunión va a salir un pensamiento “mejor” que el que una persona por sí sola podría obtener. Pero hay ciertos síntomas en los grupos que nos indican que no está capacitado para tomar decisiones correctas.
A esto se le llama groupthink (pensamiento grupal) y hay varios ejemplos en la historia de decisiones de grupo equivocadas, como por ejemplo, la negativa del ejército americano a reconocer que un ataque sobre Pearl Harbour era posible.
Así que antes de reunirte para decidir, intenta prevenir una búsqueda de un pensamiento grupal erróneo. Y es que como dice Larry Page, cofundador de Google, "ninguna decisión que tome la compañía debería esperar a mantener una reunión para adoptarla".
Es un valor a fomentar en el grupo como algo fundamental. Algo que puede ayudar a que comiencen a la hora fijada es que los asistentes marquen en la convocatoria su asistencia o no, de esta manera no se espera a alguien que no va a venir.
Este valor se trabaja en el día a día, con pequeños gestos como éste.
Que haya un guión conocido por todos puede ayudar a ir al grano y que una vez acabado, no se divague más, sino que… se sale de la sala.
Que tengan un tiempo máximo de duración y que se cumpla. Incluso si tiene varias partes, se puede poner un tiempo fijado máximo para cada una.
Que la sala disponga de los medios adecuados como papeles, bolis, pizarra y rotuladores, conectores HDMI y pantallas/proyectores…
Esto parece una tontería, pero en determinados ámbitos laborales me he encontrado que no hay unas condiciones mínimas para trabajar y si esto es así, mejor no celebrarla.
La propia distribución de los asistentes en la sala, intentando ser circular (alrededor de una mesa uniformemente) y repartida (sentándose de manera intercalada los más cercanos, evitando nichos de relativos a área o proyecto), ayuda a mejorar la comunicación y confianza entre asistentes.
También hay que poner atención en la temperatura, la ventilación, el olor, agua disponible…
Las reuniones normalmente tienen un antes (una preparación previa) y un después (unas consecuencias o acciones). Es responsable y respetuoso hacia el tiempo de los demás realizar esas tareas.
En la reunión deben estar los que tengan que estar (me apoyo en la famosa regla de las dos pizzas de Jeff Bezos, Amazon).
No todos tenemos el mismo carácter para dar una opinión. Da espacio a todo el mundo para expresarse. Busca el consenso e intenta evitar la dictadura de la minoría intransigente (los más intransigentes imponen su opinión al resto, que son más conformistas).
Hay personas que tienen facilidad para imponer su opinión y no tiene por qué ser la correcta. Hay una técnica de “preguntas rebote” que puede ser útil y que se puede ilustrar fácilmente con frases de este tipo: "Es interesante lo que dices, a ver que opina el resto del grupo".
A veces la falta de confianza entre los presentes puede arruinar una reunión. No siempre aplica esto, pero si se trata de un grupo que va a tener que trabajar durante un tiempo juntos, puede ser interesante realizar dinámicas de team building previas.
La innovación es fundamental, buscando siempre que la gente esté activa. Esto ayuda a cambiar el tradicional concepto de reunión y abraza uno nuevo: colaborativo, divertido y de aprendizaje. Por ejemplo:
Por último y no menos importante: pon el foco (¡Foco! uno de los valores de Scrum) y termina tus reuniones dando soluciones.
¡Ah, una cosa más! Además de cuidar las reuniones, respeta también los momentos de trabajo y concentración de tus compañeros. Si no hacemos “reuniones” fuera de las reuniones, también fomentamos una mayor productividad.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.