Hace unos años en España, se puso de moda un anuncio de una marca de neumáticos que decía que «la potencia sin control no sirve de nada». Y hoy, leyendo este post de alguien que trabaja en una empresa «tradicional», me viene a la mente de algo que vengo pensando hace ya mucho tiempo: que la agilidad sin control no sirve de nada.
Cualquiera que haya leído sobre el agilismo, se habrá empapado de sus principios básicos: colaboración de todos con todos, motivación del equipo, adaptación al cambio, buenrrollismo institucionalizado, oficinas cool, etc. Todo esto está muy bien, pero podrás llevarlo a cabo si se cumple una premisa: que exista confianza. Sólo si confías hasta las últimas consecuencias en tu equipo, en tus clientes, en la dirección de tu empresa, etc., puedes aplicar el agilismo puro sin riesgo a que ocurra una catástrofe.
Pero ¿qué ocurre si no puedo confiar en todos al 100%? ¿Y si tengo clientes que no respetan lo pactado? ¿Y si la dirección presiona de forma insostenible hasta abortar los sprints? ¿Y si tengo un equipo que no está motivado y/o no cumple con aquello a lo que se compromete? Entonces entra en juego el lado oscuro de la fuerza: el control.
¿Cómo se puede compatibilizar el control con una filosofía tan abierta y libre como el agilismo? Las propias metodologías ágiles establecen mecanismos de control, aunque muy sutiles, y a veces disfrazadas para que nadie se sienta controlado: por ejemplo el scrum diario, donde el scrum master vigila el cumplimiento de la metodología, revisa la desviación respecto a las estimaciones, hace seguimiento de los impedimentos, etc. O la demostración de fin de sprint, donde el product owner verifica si se han cumplido los hitos con los que el equipo se había comprometido al inicio del sprint. O un proceso de integración continua, que no es más que un mecanismo de control del código a través de test unitarios, análisis estático del código, pruebas de rendimiento, etc.
Además, es típico pensar que el control es un concepto de dos estados: control ferreo (procesos clásicos como CMMI, SPICE, etc). o libertad absoluta (metodologías ágiles, ambientes googleros, etc.) y no hay nada más lejos de la realidad. Entre el control absoluto y la libertad total hay muchos niveles, y una de las responsabilidades del scrum master es decidir qué nivel de control es necesario para llegar a buen puerto e ir adaptándolo conforme evoluciona el proyecto, el cliente, el equipo, etc.
Más de una vez y de dos me ha ocurrido que un programador, firme defensor de los modelos ágiles, se ha ofendido cuando el scrum master ha ido a pedirle explicaciones sobre algún tema. ¡Me estás microgestionando! ¡Esto no es ser ágiles! Pues perdona pero no, ser ágiles no es sinónimo de «hago lo que me da la gana y no doy explicaciones a nadie», sino ser un buen profesional en el que poder confiar, asumir que el objetivo del agilismo es ofrecer mejores resultados (y no tener lámparas de lava en la oficina) y entender que el desarrollo de software es un juego de equipo y por lo tanto los aciertos y errores de cada uno afectan y deben ser conocidos por los demás.
Me encantaría que existiesen más proyectos sin ninguna necesidad de control, pero la realidad real me dice que es una utopía, hacia la que caminar, pero utopía al fin y al cabo.
Y tú, ¿has llegado ya al horizonte de la utopía? ¿O al menos has encontrado un camino más directo para ella?