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  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.  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.