ES 
EN 
JA 
IT 
¿Nadie tiene tiempo para eso?
Ha marcado su tercera llamada de MS Teams del día. Una hora más tarde cuelgas y te preguntas cuál era el propósito. No te preocupes, piensas, ¿quizás te resulte más útil la próxima semana? Todos hemos estado allí y, sin embargo, decidimos seguir asistiendo. Antes de profundizar en los eventos de Scrum, creo útil compartir algunos consejos que Elon Musk les dijo a sus empleados de Tesla:
Detén las grandes reuniones. Deshazte de las reuniones frecuentes. Abandona una reunión si no estás contribuyendo. Deja la jerga. Comunicarse directamente, independientemente de la jerarquía. Siga la lógica, no las reglas.
Para aquellos que no conocen el carismático estilo de liderazgo de Musk, su enfoque se basa en empoderar a individuos y equipos para que hagan las cosas. Sus empleados pueden esperar que su dirección les dé lo que necesitan y no se interponga en su camino, pero lo más importante es que el equipo debe descubrir lo que necesitan y hacerlo transparente. Todo el mundo es responsable y aquí es donde entra en juego Scrum.
Los Scrum Teams son efectivos cuando se autogestionan. Lamentablemente, es un concepto que comúnmente se malinterpreta; confundirlo con el hecho de que el equipo gestiona toda su existencia sin el apoyo de su organización; este no es el caso. La autogestión es cuando un equipo decide quién hace qué, cuándo y cómo y, lo que es más importante, los eventos Scrum sustentan este concepto. En entornos complejos (donde se desconoce más de lo que se sabe), es vital contar con las personas más cercanas al problema. La capacidad de girar rápidamente, respaldada por un rápido tiempo de comercialización y controles de calidad estrictos, es el núcleo de lo que realmente significa Business Agility.
Pero, y hay un gran pero, cuando los equipos Scrum no están capacitados para autogestionarse y controlar su propio destino, el valor siempre se verá afectado. La razón se debe al ciclo de retroalimentación empírica subyacente de Scrum que requiere transparencia, inspección y adaptación frecuentes, pero es común que nuestros usuarios estén demasiado ocupados para ayudarnos a inspeccionar nuestro trabajo. En consecuencia, los eventos de Scrum se vuelven menos impactantes, más formulados y eventualmente llegan a un punto en el que un equipo dirá: "¿Podemos simplemente aplastar estas dos reuniones juntas?". Para un Scrum Master, eso es una chispa a punto de encender un incendio forestal: su equipo ahora está en un punto en el que no ven el valor de cada evento de Scrum, por lo que quieren acortarlos.
Para aquellos interesados en saber por qué se llama "evento" Scrum en lugar de "reunión", se debe en parte a la psicología (los eventos suenan más importantes e impactantes), pero también porque cada uno tiene un resultado y acciones claros. Cuando surge la sensación de que "nadie tiene tiempo para eso", entonces estamos perdiendo una oportunidad para que nuestro equipo pueda lidiar con la volatilidad y la incertidumbre. Las cosas cambian y los eventos nos ayudan a decidir formalmente las adaptaciones que debemos hacer para mejorar nuestra oferta de valor y aumentar nuestro retorno de la inversión. Scrum proporciona cinco de estos eventos que forman parte del marco, ¿puedes nombrarlos?
Scrum diario – Un evento con un cronograma de 15 minutos para que los Desarrolladores (el Scrum Master y el Producto pueden asistir pero generalmente no participan) para que inspeccionen el progreso realizado hacia su Sprint Backlog en las 24 horas anteriores. Sus discusiones se centran en el objetivo del Sprint y pueden resultar en que se agreguen o eliminen elementos del Sprint Backlog.
Planificación de sprints – Un evento con un cronograma de 8 horas para que todo el equipo Scrum discuta el por qué (objetivo del Sprint), el qué (el Backlog del Sprint) y el cómo (el plan) del Sprint. Lleva mucho tiempo y, cuando se hace bien, mitiga la necesidad de reuniones adicionales.
Revisión de sprint – Un evento de 4 horas de duración para que las partes interesadas (organización y usuarios) invitadas por el Product Owner para inspeccionar el incremento producido por el Scrum Team. Sólo se puede inspeccionar y presentar el trabajo que cumpla con la Definición de Hecho, pero esto no es simplemente una demostración, es una discusión de trabajo. Los resultados son un Product Backlog reordenado y, con suerte, una mejor comprensión de en qué centrarse en el próximo Sprint.
Retrospectiva de Sprint – Un evento cronometrado de 3 horas para que el Scrum Team reflexione con honestidad y transparencia sobre su proceso. Consideran lo que necesitan mejorar en el próximo Sprint y pueden agregar trabajo a su Sprint Backlog para abordar estas mejoras.
El sprint – El evento encapsulante que contiene a todos los demás. Cada Sprint es un miniproyecto y debe tratarse independientemente de otros Sprints. Proporciona un esfuerzo breve enfocado en un solo objetivo de Sprint.
Volviendo al punto de Elon sobre detener las grandes reuniones, los plazos parecen bastante grandes, ¿verdad? Estoy de acuerdo, pero estos plazos son máximos y no mínimos; lo que importa es el resultado. La autogestión se trata fundamentalmente de que el Equipo Scrum facilite ellos mismos estos eventos y controle el ecosistema de su Producto. ¿Quizás sea útil comparar un equipo Scrum con un equipo de médicos? Una matrona te trae al mundo, los médicos te cuidan continuamente y cuando las cosas van mal, te recomponen. Un equipo autogestionado es multifuncional para poder hacer todas estas cosas (elaboración de requisitos, escritura de código, pruebas, infraestructura y lanzamiento) y actúa para reducir cualquier dependencia que tenga de otras personas.
Si se encuentra en una posición en la que el valor de sus eventos Scrum está disminuyendo, pruebe el enfoque BEAF; límite, ejecución, acción, fin. Comience afirmando lo que (como colectivo) está tratando de lograr; puede limitar las tangentes y afirmar el valor en presencia de todos. Continúe con una ejecución nítida, centrada exactamente en lo que está tratando de lograr y nada más. Cierre con las acciones asignadas y su finalidad. El cuarto punto es obvio pero a menudo se olvida: si terminas antes, ¡termina el evento! No llenes el calendario. Muestre respeto a los asistentes logrando el resultado y terminando temprano, o al menos a tiempo.
Un último punto a tener en cuenta sobre los eventos Scrum, las reuniones y la agilidad en general son las "métricas". Usted necesita absoluta e inequívocamente comprender el impacto del trabajo que realiza (un buen recurso para consultar es la Guía de gestión basada en evidencia) y esto a menudo se olvida. ¿Podrías demostrar de forma cuantificable cada Sprint que has avanzado? Al hablar con los líderes, ¿podría mostrarles el dinero que ha ahorrado a través de una iniciativa? Si bien usted puede encontrarse en una situación única ya que es tanto cliente como proveedor, no es descabellado esperar que estas métricas se recopilen como una herramienta para ayudarnos a inspeccionarnos a nosotros mismos. Cualquier equipo autogestionado debería entender esto.
En resumen, asegúrese de que sus reuniones y eventos Scrum tengan un propósito para todos. Si no es así, tienes un problema, porque cuando surge la volatilidad, y siempre ocurre, estarás en peor posición que un equipo que regularmente ejercita un circuito de retroalimentación empírica. Si no está seguro de si sus eventos están dando en el blanco, simplemente considere: "¿Ofrecí u obtuve algún beneficio por estar aquí?". – si tu respuesta es no, plantealo en la próxima Retrospectiva de Sprint y trabaja con el equipo para solucionarlo.
En palabras del GIF del mismo nombre:
