Es una mirada crítica a la nueva reunionitis que genera Scrum comparada desde la perspectiva de productividad de Elon Musk sobre las reuniones y sobre ser productivo.
La reunionitis como fenómeno humano y no organizacional.
La reunionitis es el término usado para expresar la inutilidad de las reuniones por diversos motivos tales como: pérdida de tiempo, innecesarias, o simplemente abuso de ellas.
En este sentido la reunionitis no es una crítica a la reunión en sí misma, sino a uso fenomenológico sobre al acto organizacional de reunirse.
Así vemos que la reunión es un rito que puede tener muchas connotaciones, que se pueden reducir a dos extremos, no excluyentes.
Momento de la demostración de poder. La reunión es el momento en que alguien con poder estructural exhibe su poder ya sea, sentándose en la cabecera de mesa, usando la silla más grande o simplemente haciendo gesticulaciones que evidencia su importante presencia. Otra forma de mostrar poder es para mostrarse complaciente y abierto a la democracia pero que según recientes estudios no son más que prácticas de manipulación. Estos casos son frecuentes en expresiones como creemos ls reunión del comité X, donde X es el término para decir, aquí los importantes diremos algo sublime.
Momento para avanzar en algo. La reunión es el momento para tomar una decisión. Es la epítome donde alguien decide algo, es el momento esperado por quien espera que alguien tome una decisión. Se refleja en frases como en la reunión lo discutimos. Así suma y sigue y nadie hace algo hasta que llega la reunión. Por ello se suele decir, reunámonos y al final por cada decisión hay una reunión. En estos casos, puede ocurrir que la cultura de los no-directivos abuse de la reunión para no decidir o han caído en el caso de que para poder decidir deben pedir estas reuniones porque nadie puede decidir sin la reunión o sin el jefe o la jefa.
En cualquiera de los casos previos no hay maldad ni pereza, o eso se espera. Simplemente son personas relacionadas en un contexto claro mostrarse y ocultarse.
Por supuesto, y no debo olvidar, están los encuentros de café, de pasillo, de ascensor, de caminata, entre otras, que en realidad son reuniones en contextos o espacios que podrían decirse son distendidos o fuera del espacio de una oficina o sala de reuniones, donde igual se debaten y deciden cosas. De hecho, conceptualmente son reuniones y se usan estos encuentros -casuales o planificados- como tal. Por ejemplo, cuando escuchamos pílllalo en el pasillo y le cuentas o cuando se planifica cuando vaya en el ascensor le digo.
Puedo acotar finalmente qué:
Es un hecho innegable que la reunionitis no es mala, sino las reuniones inútiles y que hacen perder el tiempo. Pero la culpa no la tienen las reuniones, sino las personas que las organizan, convocan y asisten.
Es un hecho innegable que Scrum está llenando de reuniones ágiles a las organizaciones, y es cierto que están apareciendo las reuniones ágiles (léase Scrum) zombies, o sea, pura inercia del tipo vamos de nuevo a la daily meet (en tono de aburrimiento). Pero la culpa no la tiene Scrum, sino las personas que creen que Agile es la panacea a la falta de disciplina en reuniones.
En cualquier caso la reunión busca ser algo útil, no inútil. Pero la frontera es sutil.
Scrum y la reunionitis Scrum.
Scrum plantea entre sus componentes principales las reuniones o eventos. Así tenemos la planning meet, la daily meet, la review meet y la retrospective meet, que pueden verse y comprenderse en la biblia, perdón, la Guía Scrum.
Cada una de esta reuniones tiene un objetivo, un formato, una estructura y un fin muy claro en Scrum. Nadie puede negarlo.
Pero miremos la evidencia.
Scrum nace en un contexto donde el resultado del desarrollo de software, o sea un software, no era adecuado o no era exitoso, y se requería una mirada distinta. Así nace Scrum como una forma colaborativa de trabajo que permitía a las personas conversar para organizarse y plantear ideas y poder atender requerimientos cambiantes, evolutivos o simplemente inexistentes. Claro, la idea es simple: conversando se entiende la gente y debatiendo se pueden tener más ideas.
Y sí, todo se trata de CONVERSAR.
Guste o no, Scrum es un espacio de conversación estructurado y que obliga a comunicarse, que no necesariamente es lo mismo que conversar. Por supuesto esto trae consigo todos los males de la manipulación, la conversación dirigida, el expolio del tímido y así muchas linduras del ser humano.
Si vemos que Scrum nace en el contexto del desarrollo de software donde las personas suelen hablar poco o son espacios laborales muy constreñidos y hay que decirlo, mucho espíritu nerd (ojo dije espíritu, no que existan personas de este tipo), un espacio como el provisto por Scrum es genial.
En otras palabras, si el trabajo en el desarrollo de software era aislado, una herramienta socializante como Scrum viene de perlas. Pero, en otros ámbitos donde la colaboración era y es más natural, Scrum es un elemento más organizador que creador de una cultura. Scrum viene a ser muy útil en organizaciones con una estructura organizacional clásica -que en suma son casi todas las organuzaciones-, pues Scrum aporta espacios de conversación que rompen los silos organizacionales.
Antes de Scrum ya existían proyectos de diverso tipo con igual -incluso mayor- complejidad creativa a la de un proyecto de software cuyos problemas se resolvían con las llamadas reuniones de proyecto (reuniones de planificación de proyecto y de actividades/tareas, reuniones de seguimiento, post mortem meet, entre otras).
Y es cierto, que en este año he podido constatar que personas que tienen seniority en proyectos del tipo o ámbito que sea, suelen aprovechar mucho mejor las reuniones Scrum o al revés, no ven Scrum como un diferenciador o como me ha pasado con ciertos ingenieros que me dicen estas cosas de Scrum ya las hacemos.
Y ahí viene la reunionitis Scrum: cuando no hay seniority.
Scrum plantea sus reuniones de forma concreta, con una periodicidad y alcance precisos. O sea, Scrum nos dice: así debe ser la reunión., qué se reporta y qué se evidencia.
Si no hay hábitos organizadores, quienes lideren una reunión Scrum, harán las cosas como antes. Por ello se aprecia que en un proyecto Scrum, las reuniones de retrospectiva son escasas, o no pocas veces, nulas, pues si antes no las hacían, pues no se hacen.
Si no hay comprensión clara de lo que es una reunión, las reuniones mueren. Así llegamos a las zombie scrum meet, o sea, reuniones donde quienes asisten son zombies. Se asiste a la reunión por obligación, y no por el sentido de Scrum. O sea, como antes en plan uff, vamos a la reunión diaria sin ninguna emoción y por puro compromiso.
Si no hay daily meet, no hay decisiones. Sí, las daily meet terminan siendo reuniones para que el líder, y muchas veces el Scrum Master o el Product Owner digan lo que hay que hacer, y todos nos sentimos bien diciendo lo que hice y haré.
Si no hay conciencia de seniority en el aprendizaje que impone Scrum pasa de todo. Scrum deja claro que la idea es avanzar en serio, no decir a cada rato cosas como vamos bien o estoy feliz y luego hacer cualquier cosa. Scrum impone una disciplina de control que si no se trae de antes se producirán problemas de gestión.
Si no hay cultura del horario, las reuniones Scrum pierden su esencia. Las reuniones Scrum demandan planificación diaria (hábito poco frecuente y en sí misma actividad desgastante -por eso se deja que otros planifiquen, a mí dime lo que hay que hacer) y puntualidad. Pero si las personas llegan tarde, no preparar su parte de la reunión, los Product Owner no asisten, y así muchas linduras humanas, las reuniones pierden la efectividad y eficiencia prevista.
Bueno, se pueden decir más cosas, pero dejemos hasta aquí.
En suma, las fallas en las reuniones Scrum siguen siendo las mismas de las reuniones tradicionales o de las llamadas reuniones no ágiles (la verdad que al ver la evidencia expuesta, no sé como se puede decir que una reunión Scrum improductiva se le siga llamando ágil).
La productividad según Elon Musk.
No nos liemos. Corre por redes sociales lo que supuestamente Elon Musk por correo mandó a sus súbditos, a sus empleados, respecto de lo que para él es productividad.
Aquí les va.
Here they are:
1) Avoid large meetings
Large meetings waste valuable time and energy.
– They discourage debate
– People are more guarded than open
– Theres not enough time for everyone to contribute
Dont schedule large meetings unless youre certain they provide value to everyone.
2) Leave a meeting if youre not contributing
If a meeting doesnt require your:
– Input
– Value
– Decisions
Your presence is useless.
Its not rude to leave a meeting.
But its rude to waste peoples time.
3) Forget the chain of command
Communicate with colleagues directly.
Not through supervisors or managers.
Fast communicators make fast decisions.
Fast decisions = competitive advantage.
4) Be clear, not clever
Avoid nonsense words and technical jargon.
It slows down communication.
Choose words that are:
– Concise
– To the point
– Easy to understand
Dont sound smart. Be efficient.
5) Ditch frequent meetings
Theres no better way to waste everyones time.
Use meetings to:
– Collaborate
– Attack issues head-on
– Solve urgent problems
But once you resolve the issue, frequent meetings are no longer necessary.
You can resolve most issues without a meeting.
Instead of meetings:
– Send a text
– Send an email
– Communicate on a discord or slack channel
Dont interrupt your teams workflow if its unnecessary.
6) Use common sense
If a company rule doesnt:
– Make sense
– Contribute to progress
– Apply to your specific situation
Mayor claridad no se puede pedir.
Solamente se puede acotar que eso lo dice un señor dueño con mucho poder. Cualquier trabajador o trabajadora claramente no podrá ser tan conciso. A ver, que nadie es Elon Musk ni Musk puede ser como otro ser humano, pero si puede imponer su punto de vista y seguramente muchos lo aplaudirán como un Dios.
El impacto de la productividad de Musk en las reuniones Scrum.
Esta es la parte fácil. Tomemos cada punto del correo de Musk.
1) Avoid large meetings.
En Scrum las reuniones tienen tiempo predefinido. Sí. Así es.
Están las de 15 minutos hasta las de 4 horas. Qué …¿?!!!! Si, de 4 horas. Bueno eso va contra la lógica de Musk.
Acá hay que tener cuidado. En Scrum se trata de la duración adecuada respetando la finalidad de la reunión. Ni cortas que no permitan avances, ni largas que sean un escarnio.
2) Leave a meeting if youre not contributing.
Acá cuidado. En todas las reuniones Scrum los actores están definidos en su rol.
Esta advertencia debe convertirse en que si pasa ésto, algo falla en Scrum.
3) Forget the chain of command.
Scrum viene a romper la estructura del proyecto con un principio basado en el valor y para ello crea, una nueva estructura.
El mensaje de Musk es claro, hay que ir a la fuente, saltarse la línea de mando que en Scrum es distinta.
Este mensaje de Musk lleva a que si vemos que el Product Owner es un eslabón inutil, hay que saltarlo. Y si el Scrum Master termina siendo un metodológico obcedado por el puritanismo de Scrum, hay que saltarlo.
4) Be clear, not clever.
Esto lo entenderán quienes más hayan vivido un proyecto Scrum: la jerga Scrum.
Parece un lenguaje de sabios.
Y ni hablar si hay un contexto informático. Entre anglicismos y palabras de moda, nadie se entera y podrías quedar fuera del nuevo club de los sabios.
5) Ditch frequent meetings.
Bueno, Scrum tiene las daily meets (esas que son de 15 minutos).
Ojo, no son frecuentes, son diarias.
Alguien dirá que tanta reunión diaria agota. Pero una vez, una persona en rol de Scrum Master me dijo que estaba en más de un proyecto y se pasaba todo el día en reuniones Daily Meet.
Ojo, no creais que un Daily Meet son 15 minutos y punto. Prepararlas y darles seguimiento consumen más tiempo.
6) Use common sense.
Acá hay algo clave.
El puritanismo Scrum genera una nueva burocracia y nuevos ghettos. Las llamadas organizaciones ágiles exitosas lo saben y aplican sentido común.
Ajustan la duración de las reuniones a la lógica del negocio, además de crear estructuras propias de operación.
En síntesis.
Scrum ha creado un nuevo espacio de reuniones que si no se elaboran con una mirada distinta, la cultura organizacional impondrá el cómo ya lo hacían antes.
Tampoco se trata de crear un nuevo mindset como se ha intentado renombrar al proceso de ahora lo haremos así para aludir a usar Scrum en las organizaciones.
Scrum ha introducido roles nuevos, muchos de los cuales se han convertido en nuevas jerarquía, pasando de la jerarquía horizontal al nuevo orden de poder de Scrum. Por más que se diga que existe ahora un liderazgo servicial, este liderazgo no escapa que pueda ser Sociópata, Egoista, Camaleónico, Dínamo, Constructor o Transcendente, por lo que es normal escuchar quejas de personas que ocupan cargos de Scrum Master o Producto Owner que no aportan valor pero tienen mucho poder es más, son un obstáculo, aunque ellos se creen especiales.
Elon Musk pone los puntos sobre las ies con Scrum.
Lo primero que nos sugiere dice es que las reuniones deben ser claras y precisas y si Scrum ya lo pide, pues que sean así. Scrum no pide reuniones que sean ritos religiosos, sino eventos de construcción de conocimiento que corporifique resultados de valor.
Lo segundo que nos sugiere es que si algo o alguien obstaculiza el trabajo, hay que saltarlo. Acá no sé si entre tanto Product Owner, Scrum Master e inclusive Agile Coach o Agile Trainner, esto se acepte. La religión Scrum a veces es demasiado impositiva.
Lo tercero que nos sugiere es que hay que hacer las reuniones que valgan la pena. Acá comparto lo que se ve y comenta. No hagas Daily Meets diarias si a lo mejor pueden ser cada dos días y/o de 15 minutos si a veces es necesario que sean de 20 minutos. Scrum apunta a la finalidad, no a imponer una estructura. O sea, sentido común a tope.
Cabría acotar solamente que hay que ser respetuoso con Scrum, lo que sugiere e indica. Además, algo que se evidencia en diversos casos reportados es que los roles de Scrum Master y Product Owner funcionan muy bien en personas con seniority en proyectos, pero poco en personas con poca experiencia en desarrollo de productos o en gestión de conflictos.
Por último, nadie ha dicho la última palabra.
¿Qué puedes aportar?
¿Crees que de las ideas de Musk podrías añadir algo más?
¿Crees que la exigencia de Musk a es aplicable a Scrum?
¿La productividad según más sería Agile?
…
Programa Gestión Ágil de Bodegas
Un programa único que aplica Agile a la gestión de una bodega.Información es inscripciones en: https://www.ilumacademy.com.ec/cursos/workshop-gestion-agil-de-almacenes
Conoce más con esta masterclass …
Un blog de Ingeniería de Proyectos
Proyectando innovaciones para personas, estrategia y sociedad
SuscríbeteDirección de correo electrónico:
Suscribir
Fuente: este post proviene de Blog sobre diseño de proyectos, donde puedes consultar el contenido original.
¿Vulnera este post tus derechos? Pincha aquí.
Creado: