Si hablamos con desarrolladores sobre el enfoque ágil de su organización, vemos que en muchas ocasiones nos trasladan los mismos problemas de agile. A continuación os hacemos una reflexión de estos
Uno de los principales problemas de agile: reuniones, reuniones, y más reuniones
Parece que el núcleo del enfoque ágil gira en torno a las reuniones. ¿Qué quiero decir con esto? Pensemos en un día normal en un entorno ágil. La primera reunión que tenemos es una reunión de pie, o si trabajamos desde casa probablemente será través de Zoom, Slack, Teams,…
Dependiendo de la cantidad de personas involucradas en este stand-up, nos puede llevar entre 15 y 30 minutos. Esta reunión suele estar dirigida por el Scrum Master -del que hablaremos un poco más adelante-, y se supone que es una reunión con el equipo técnico. Cada técnico dirá lo que hizo ayer, lo que está haciendo hoy, si tiene bloqueadores y cuáles son.
Esta reunión es muy repetitiva y seguro que todos hemos participado en muchas reuniones en las que apenas se habla o siempre hablan los mismos de lo mismo. Seamos claros: no estoy diciendo que no debamos comunicarnos con el equipo o que estar de pie sea necesariamente algo malo. Sin embargo, si no hay novedades, ¿por qué tener una reunión? ¿Por qué interrumpir el flujo de trabajo del equipo si no se va a decir ni a hacer nada importante?
Liderazgo Agile
Se supone que Agile es para un marco definido para y por los técnicos, ¿verdad? A un grupo de técnicos se les ocurrió Agile para reemplazar metodologías “waterfall”, y se suponía que sería la panacea para mejorar los procesos de desarrollo de software.
El principal problema es que muchas personas no tienen ni idea de cómo funciona el desarrollo de software en el mundo real. Solo saben lo que se les enseña en un curso de Agile de 2 días. Esto se hace evidente cuando insisten en cosas que simplemente no tienen sentido. Una de esas cosas es involucrarse en discusiones técnicas. Muchas veces nos pasamos de 10 a 15 minutos tratando de explicar los detalles técnicos a alguien que no es técnico. También terminamos teniendo que repetirnos constantemente porque no cuentan con la base técnica necesaria. Esto es algo que no tiene absolutamente ningún sentido y algo que vemos frecuentemente.
Muchas veces el liderazgo ágil intenta incluir a demasiadas personas en una reunión, a menudo los Scrum Master intentan incluir tantas personas como le sea posible en una reunión. Pongamos un ejemplo. Una empresa ha decidido introducir una nueva función en el producto principal. Se han dado todos los requisitos y ahora los equipos técnicos deben encontrar una forma de introducir la función. Es lógico que haya una discusión técnica sobre cómo encajar mejor esta pieza en el rompecabezas. Este es un ejemplo de una reunión que SOLO debería ocurrir entre los líderes técnicos para preparar los requisitos técnicos para sus equipos.
Sin embargo, lo que a menudo sucede es que los Scrum Master piensan que todo esto debería hacerse mediante la democracia, y se incluyen a los Scrum Masters, Product Owners, Developers… Esto esta relacionado con lo que comentábamos antes:
Dedicamos tiempo a explicar las cosas técnicas a las personas que no necesitan conocer los detalles técnicos, y esto es una pérdida de tiempo que no aporta ningún valor a nadie.
Como líder de un equipo, trataremos de asegurarnos de tener todos los detalles técnicos resueltos antes de que el trabajo llegue al equipo. Asegurarnos de ser nosotros quienes programemos las reuniones y solo incluyamos a las personas que realmente necesitemos que estén. Esto suele dar como resultado una liberación más rápida del producto.
Solucionar los problemas de agile
Hay problemas y estos tienen que tener una solución, ¿verdad? Bueno, esta es una respuesta más complicada de lo que parece. Debemos hablar sobre algunos problemas específicos que hemos detectado y sobre todo de cómo resolver esos problemas o como los hemos resuelto en anteriores ocasiones en caso de ser repetitivos.
Resolviendo las reuniones
Una solución particularmente útil es realizar reuniones de pie asincrónicas. Por ejemplo, Slack tiene muchas herramientas realmente buenas, como puede ser la encuesta automatizada. Uno de los principales beneficios del stand-up es lo último de lo que se habla, los bloqueadores. Si hay bloqueadores, sin duda es beneficioso descubrirlos antes de que avance la jornada. De lo contrario, encontraremos que el stand-up generalmente es una pérdida de tiempo.
Enviamos una encuesta al equipo antes del stand-up para preguntar si deberíamos tener una reunión síncrona o de stand-up. Se acuerda que esta pregunta significa si hay bloqueadores o elementos pendientes que requieran conversación. De lo contrario, publicamos nuestras actualizaciones normales en el canal de slack del equipo y las analizaremos allí.
Este proceso lleva mucho menos tiempo, obtiene el mismo beneficio y no es perjudicial para el flujo de trabajo. Esta es una sugerencia que puede ser increíblemente beneficiosa para un equipo que va en contra del agile estándar.
Resolviendo el liderazgo
Los técnicos deben estar a cargo de los aspectos técnicos. Es necesario que se ponga más control en manos del liderazgo técnico. Si en el equipo hay un Scrum Master no técnico, debería ser una ayuda al liderazgo técnico, no el liderazgo técnico en sí mismo.
Los Scrum Masters no deberían dictar los procesos en torno al código que se escribe o se implementa. Si vamos a tener un Scrum Master no técnico, debería tener una responsabilidad limitada. Si alguna vez hemos visto como se trabaja en una cocina, hay una persona que agiliza los pedidos en la cocina. Esta persona no es un chef / cocinero, pero toma los pedidos, los organiza y luego los lleva a la cocina. Los acelerados no saben, ni necesitan saber, cómo se hace la comida, pero ayudan a que todo ruede más rápido.
El otro problema es el de tener demasiadas personas en cada reunión.
A menudo, a los Scrum Master les gusta atraer a todos a las reuniones que en realidad solo deberían tener unas pocas personas. Esto parece una solución relativamente sencilla, tengamos reuniones más enfocadas. De esa forma la reunión es más productiva y se pierde menos tiempo.
Ideas finales
Al final del día, lo que funciona para cada equipo suele ser diferente. Me encuentro que la forma en que se implementa Agile hoy en día es muy rígida e intenta implementar lo mismo en todas partes, y así nunca funcionará. Animaría a los equipos técnicos a rechazar este paradigma y hacer cosas diferentes que tengan sentido en sus equipos y proyectos, y no seguir al pie de la letra la teoría de un manual.
Y si tienes dudas y te apetece que te asesoremos, no lo dudes. Aquí puedes ver cómo es nuestra forma de trabajar en lo que a consultoría de cambios culturales se refiere. O, si lo prefieres, puedes contactar con nosotros.