El declive de una idea revolucionaria
Hubo un tiempo en que Agile representaba una esperanza para los equipos de desarrollo. Prometía libertad, colaboración y capacidad de adaptación en un mundo dominado por los procesos rígidos y la microgestión. Con los años, sin embargo, en muchos lugares acabó pareciéndose precisamente a aquello que pretendía combatir: un conjunto de normas burocráticas e inflexibles. Hoy hay equipos que temen oír la palabra «Agile» porque la asocian con ceremonias interminables, artefactos poco prácticos y la obligación de seguir el manual incluso cuando hay una solución mejor.
El espíritu original de Agile
En 2001, el Manifiesto Ágil expresó cuatro preferencias:
- Las personas y sus interacciones por encima de los procesos y las herramientas.
- El software que funciona por encima de la documentación exhaustiva.
- La colaboración con el cliente por encima de la negociación contractual.
- La respuesta al cambio por encima del seguimiento de un plan.
La intención era dar a los equipos margen para resolver problemas y entregar algo de valor, sin imponerles una liturgia. En algún momento perdimos de vista esa intención.
Dónde perdimos el rumbo
1. La ceremonia por encima del sentido común. Los equipos acumulan reuniones diarias, planificaciones del Sprint, retrospectivas, sesiones de refinamiento del backlog y un largo etcétera. Todas pueden ser útiles. Si se celebran por inercia, sin relación con una necesidad real, se convierten en una carga. A muchos equipos se les exige demostrar que «hacen Agile»: se comprueba si cumplen cada ritual y se pregunta menos qué han conseguido.
2. Los artefactos como fin en sí mismos. El Product Backlog, los gráficos de trabajo pendiente y las historias de usuario nacieron para facilitar el trabajo. En muchas organizaciones se han convertido en el centro de atención. El equipo dedica más tiempo a perfeccionarlos que a resolver el problema que deberían ayudarle a abordar.
3. Una única receta para todos. Agile debía adaptarse a los equipos. En la práctica, algunos Scrum Masters y coaches ágiles intentan encajar a todos los equipos en un molde. La metodología estándar acaba pesando más que las necesidades, las relaciones y los objetivos particulares de cada uno.
4. La obsesión por las métricas. Cuando la velocidad o los puntos de historia se utilizan como armas, los equipos aprenden a mejorar sus cifras sin mejorar lo que entregan. Se deteriora la confianza y los números empiezan a importar más que los resultados.
El papel del Scrum Master
Pocas responsabilidades se han entendido tan mal como la del Scrum Master. Concebida como una forma de liderazgo al servicio del equipo, a menudo se confunde con la dirección de personal, la gestión de proyectos o la administración de trámites. Esa confusión ata de manos a los equipos y desvirtúa el propósito de Agile.
¿Qué debería hacer un Scrum Master?
- Facilitar el trabajo. Su primera responsabilidad es ayudar al equipo a utilizar las prácticas ágiles con autonomía. Puede conducir una reunión cuando hace falta y ayudar a comprobar si de verdad contribuye a los objetivos del equipo.
- Escuchar al equipo. Un buen Scrum Master intenta entender las dificultades y necesidades concretas de las personas. Escucharlas le permite ayudar a resolver obstáculos y crear condiciones para la confianza y la colaboración.
- Mejorar la comunicación. Tanto dentro del equipo como en su relación con las partes interesadas, puede hacer que la información sea más clara y accesible y que las personas se entiendan mejor.
- Animar al equipo a tomar la iniciativa. Hay que dejar espacio para asumir responsabilidades, probar ideas e innovar sin miedo al fracaso. Un equipo con esa libertad responde mejor a los contratiempos y encuentra soluciones más creativas.
- Evitar imponer reglas. El Scrum Master no está para repartir tareas o hacer cumplir su propia visión. Ayuda al equipo a descubrir lo que mejor le funciona.
- Renunciar al papel de jefe. Tampoco es el jefe jerárquico ni el director del proyecto. Conviene resistir la tentación de controlar la producción del equipo o dictarle cómo trabajar. Su misión es hacer posible el trabajo del equipo.
Así se recupera una figura capaz de defender al equipo en vez de vigilar su fidelidad a una ortodoxia.
Cómo recuperar el rumbo
Para devolver a Agile su sentido hay que revisar sus orígenes y reconstruir las prácticas con sentido común, dejando las decisiones de trabajo en manos del equipo.
1. Empezar por los principios. Antes de aplicar ceremonias y artefactos al pie de la letra, conviene preguntar para qué sirven. ¿La reunión diaria mejora de verdad la comunicación? Si no lo hace, habrá que adaptarla o prescindir de ella.
2. Dejar decidir al equipo. Cada equipo debería elegir las prácticas que responden a sus necesidades. Podemos ofrecer orientación sin convertirla en una orden. Agile debe servir de marco, no de camisa de fuerza.
3. Medir el resultado que obtiene el cliente. Recuperemos el foco en el valor entregado. El software que funciona y la satisfacción del cliente dicen más sobre el éxito que un gráfico de velocidad o una suma de puntos.
4. Replantear el papel del Scrum Master. Hace falta alguien que facilite la colaboración y ayude al equipo a prosperar. Un funcionario que se limite a imponer normas difícilmente cumplirá esa función.
Agile aún puede transformar la manera en que trabajan los equipos si recuperamos su propósito original. Cuando damos prioridad a las personas, a la adaptación y a lo que resulta valioso, vuelve a ser una herramienta que otorga autonomía en lugar de quitarla.
Para recuperar lo mejor de Agile, empecemos por recordar qué lo hizo valioso.