Tabla de contenidos
Introducción
En la lista de actividades en el ciclo de vida de desarrollo de software Scrum clasificadas por su popularidad entre los desarrolladores, «asistir a reuniones» compite quizás con «escribir documentación» por la posición del último lugar. Es bastante comprensible: las reuniones Scrum pueden llegar a ser muy aburridas – especialmente cuando un participante no tiene nada que aportar a la reunión en cuestión – y son a menudo percibidas como de poco valor (si acaso) en comparación con la realización de la escritura de código real en el proyecto de desarrollo de software. Sin embargo, estas reuniones Scrum pueden aportar valor al proyecto, y de hecho lo hacen, aunque los miembros del equipo no lo perciban:
- Los refinamientos de sprints permiten al propietario del producto y al equipo planificar las tareas de desarrollo de las próximas semanas o meses, así como identificar si alguna tarea necesita un examen o diseño más detallado.
- Los sprint plannings definen el trabajo que el equipo debe realizar en el periodo del sprint.
- Las demostraciones de sprints proporcionan visibilidad a otros equipos y/o partes interesadas del proyecto sobre lo que un equipo está trabajando y ha logrado, y permite hacer preguntas para obtener claridad sobre el trabajo (o incluso retos para garantizar que el trabajo producido es sólido y ha cumplido todos los objetivos).
- Las retrospectivas de sprints permiten a un equipo identificar factores del sprint anterior que fueron bien recibidos, que podrían abordarse para su mejora o eliminación, etc.
Esto es, por supuesto, simplemente recitar de la doctrina de Scrum. Cualquier beneficio que estas reuniones Scrum puedan esperar proporcionar no aparecerá si los participantes de la reunión no están interesados en «jugar su papel» en dichas reuniones – ¿Qué se puede hacer entonces? Se podría:
- Vestir las reuniones Scrum con metáforas bonitas – por ejemplo, el uso de tallas de camisetas en lugar de puntos de póquer para la estimación del esfuerzo de la historia durante el refinamiento del sprint. Esto sigue dejando claro que las reuniones son exactamente lo que son, es decir, los gastos generales de un proyecto que los miembros del equipo tienen que superar a duras penas.
- Basta con insistir en las ventajas de Scrum y apelar a la profesionalidad de los miembros del equipo para que den un paso al frente y aporten lo necesario para la reunión. Incluso con el motivador más hábil llevando a cabo este discurso, se corre el riesgo de sonar intimidante y podría llevar a cabo el efecto contrario.
En lugar de eso…
Por muy bienintencionados que sean estos intentos, no suelen conseguir despertar el entusiasmo o la aceptación de las reuniones Scrum. En mi opinión, esto se debe a que el proceso de pensamiento que subyace a los esfuerzos se limita a la definición tradicional de las reuniones: se siguen celebrando como reuniones estándar en las que la descripción de cómo debe ocurrir se sigue casi punto por punto. En cambio, es posible hacer que estas reuniones sean menos «dolorosas» para los implicados de otras maneras empleando algunas ideas originales. Para ello, me gustaría ofrecer dos ejemplos de mi propia experiencia de trabajo en LucaNet sobre formatos de reuniones que mejoraron la participación sin dejar de ofrecer el mismo resultado deseado.
Ampliar el alcance: Demostraciones Sprint
A primera vista, el objetivo de la demostración del sprint parece muy sencillo: que los equipos del proyecto hagan una demostración de lo que han conseguido en el sprint anterior. Esto suele venir con la condición añadida de que estas demostraciones estén relacionadas con los objetivos del sprint de los equipos; ¿qué pasa si no hay tal restricción para los equipos? La demostración del sprint podría transformarse en una especie de reunión interna, en la que los equipos no sólo hicieran una exposición de lo que han trabajado en sus proyectos, sino que también presentaran temas que consideraran que podrían beneficiar a los demás equipos. Por ejemplo, un equipo cuyos miembros se inclinen por experimentar y explorar temas relacionados con el rendimiento podría presentar sus conclusiones sobre patrones de lenguajes de programación a adoptar (¡o a evitar!), mientras que otro equipo podría mostrar una nueva tecnología que haya investigado. Además de permitir que los desarrolladores presenten los temas que realmente les interesan, permitir este tipo de presentaciones tiene la ventaja añadida de que equipos que de otro modo no participarían en estas reuniones también lo hagan, por ejemplo, un equipo de soporte técnico que normalmente no tendría trabajo relacionado con el sprint de desarrollo. Dado que estas reuniones llevarían sin duda más tiempo que otras en las que sólo se presentaran temas relacionados con el sprint, sería beneficioso adoptar otros aspectos de las reuniones de demostración técnica, como ofrecer comida y bebida a los asistentes, permitir la votación (y pequeños premios) para la «mejor» presentación, etc.
Eliminar la formalidad: Retrospectivas de sprints
Es posible dar un paso más: en lugar de modificar las actividades «permitidas» de la reunión, ¿por qué hacer una «reunión de trabajo»? El objetivo de la retrospectiva del sprint es obtener comentarios de los miembros de un equipo sobre cómo ha ido el sprint anterior, qué conservarían/mejorarían/eliminarían, etc. Esto requiere la comunicación de los miembros del equipo sobre sus experiencias, y dicha comunicación sobre experiencias pasadas y las opiniones al respecto es, en efecto, una conversación de grupo. Hay otros entornos en los que se puede cultivar este tipo de conversación de grupo; un ejemplo sería una comida de equipo. El equipo se reúne para comer -desayuno, comida, cena, lo que sea- y hablar de sus experiencias durante el sprint anterior mientras comen y conversan sobre cualquier otro tema que tengan en mente. El organizador decide si la comida la proporciona la empresa o los participantes en la reunión, aunque el hecho de que la proporcionen los participantes (además de ser más barato para la empresa) añade la intriga de un «pot-luck» en el que los participantes pueden presentar a sus colegas comidas que de otro modo no conocerían, algo especialmente significativo cuando se trabaja en un equipo con miembros de diferentes ciudades o países. Sin embargo, la principal ventaja de este enfoque es el ambiente que ayuda a crear. En el fondo, la retrospectiva del sprint es un ejercicio de catarsis: los participantes «descargan» los sentimientos -tanto positivos como negativos- que han acumulado durante el sprint acerca de cómo se ha desarrollado éste. Al convertir esta reunión en una comida compartida, el entorno pasa de lo formal a lo informal, y esta relajación del ambiente puede ayudar a extraer estos sentimientos de los participantes mejor que en el formato tradicional de la reunión, lo que se traduce en una retroalimentación más eficaz y, por tanto, en una aportación más efectiva sobre cómo mejorar futuros sprints en el futuro.
Conclusión
Hay que matizar aquí que las prácticas descritas anteriormente se produjeron en la era pre-COVID, es decir, antes de la adopción generalizada del trabajo a distancia. Sin duda, algunas de las prácticas tendrían que adaptarse a las empresas cuyos equipos están formados por miembros que nunca (o casi nunca) se ven en el mundo físico -por ejemplo, celebrar desayunos de equipo a través de una videollamada y desde el comedor o la cocina de cada miembro del equipo- y también existe la posibilidad de que los efectos productivos de los planteamientos sean diferentes para los equipos remotos en comparación con los equipos presenciales. No obstante, el principio básico sigue siendo que puede merecer la pena desafiar las convenciones de los formatos de reunión tradicionales para descubrir si alguna modificación de las reuniones de un grupo puede dar lugar a equipos más productivos y comprometidos. Reinventar la rueda no tiene por qué ser la solución definitiva; es muy posible que lo que ya se ha prescrito sea la mejor solución para el equipo en cuestión. Sin embargo, incluso en esos casos este ejercicio puede resultar beneficioso, ya que el resultado final seguiría siendo una introspección sobre lo que realmente sirve al equipo para su proceso de desarrollo.
