La agilidad surgió como respuesta a dos graves problemas en los años 90s, ya que el pésimo ambiente laboral –desde la perspectiva de los trabajadores- los enfrentaba a horarios interminables, gran presión, individualismo y frustración ante la falta de logros y de reconocimientos. Además, existían deficientes resultados de los proyectos de software para los negocios, donde se sufrían los múltiples retrasos e incumplimientos, incluso irónicamente “celebrando” cumpleaños de proyectos a medida que se eternizaban. Pero el origen del movimiento ágil es mucho más rico, pues está basado en potenciar aquello que realmente funcionaba en proyectos exitosos y luego: potenciarlo, como por ejemplo la familia de métodos Crystal (Alistair Cockburn) que nace de las observaciones etnográficas de muchos equipos alrededor del mundo, o The New New Product Development Game (Takeuchi y Nonaka) qué inspiran a Scrum (Sutherland y Schwaber)
Al plantearse como contramovimiento al modelo clásico de etapas secuenciales en cascada, la agilidad se estableció / planteó sin una base conceptual, volviéndola propensa a modas pasajeras como OKRs, Management 3.0 o SAFe. Herramientas que prometen innovación sin fundamentos sólidos: Como un árbol con raíces débiles, la agilidad se tambalea ante cada ventolera (hablemos del árbol) que viene y va , como los OKRs, Management 3.0, Estructuras Liberadoras, SAFe etc.
En esta vorágine que definía la época, muchas empresas creyeron que la agilidad se lograba adoptando ciertos roles.
Se contrataron “scrum masters” sin experiencia técnica para entender a sus equipos, o “product owners” sin visión del negocio. Al tener que demostrar su valía 40 horas a la semana, se tiende a ahogar a los equipos en rituales sin sentido.
Entorpecen el avance en lugar de fomentarlo. Es importante notar que ambos roles requieren de contar con una red de contactos al interior de la organización, en el caso de Scrum Master para eliminar impedimentos, y del Product Owner para obtener información útil para priorizar el Trabajo para que genere más valor.
Peor aún fue asignar por ordenanza (o un sinónimo de RRHH, pero que no se repita con el del título) a estos roles críticos a personal interno sin preparación adecuada, tras capacitaciones exprés de 2 días. Un modelo de negocio tan rentable como engañoso.
Por un lado, tenemos empresas que venden roles ágiles, que no entienden la cultura de la empresa a la que llegan, o capacitaciones certificadas express que no entregan reales nuevas capacidades a los alumnos.
Por otro lado, hay quienes se dedican a la capacitación en agilidad sólo conociendo la Teoría ágil y a realizar actividades entretenidas en sus talleres, lo que les tienta a hablar con una seguridad que da miedo y transmite aún más confusión a los novicios. En consecuencia, sus alumnos quedan maravillados pero sin apoyo para llevar lo aprendido a la práctica. Este fenómeno ha sido llamado Agile Flower - mucha labia de gente que nunca ha sacado adelante un proyecto en la realiad.
Toda disciplina tiene un sistema para evaluar las habilidades de sus practicantes y formadores. El nuestro sólo ha logrado ganancias a corto plazo. En el lado positivo, algunos ya colgarán el diploma de disciplina ágil buscando el próximo hype.
Las organizaciones que abordaron la necesidad de transformarse digitalmente adoptaron en su inmensa mayoría una estrategia de cambios de estructura costosisimos (equipos ágiles - llamados “células” - formados de forma inorgánica y con un apuro irreflexivo) y con liderazgos, tal como vimos antes: inadecuados por su falta de conexión con el negocio o falta de experiencia en agilidad.
Algunos efectos Indeseados son:
Las nuevas estructuras ágiles nacen desconectadas del negocio inicial de la empresa:
Muchos C-Level de empresas manufactureras o de servicios no digitales asumieron que para transformar digitalmente sus organizaciones ellos podían comprar recetas (muchas veces muy complejas, para aparentar ser valiosas) en vez de aprender sobre la naturaleza incierta del desarrollo digital y aprender a navegarlo.
Eso se produce porque:
El echar a andar la máquina de células desarrolladores puede efectivamente aumentar la tasa de entrega de los productos. Pero esto sólo funciona a corto plazo.
Cuando los desarrolladores de software no dominan las prácticas básicas de desarrollo ágil como el Diseño Guiado por Dominio o aquellas propuestas en Extreme Programming tales como el testing automático, la refactorización sin piedad del código, el diseño sencillo emergente, sistemas de gestión de versiones concurrentes, programación colaborativa, entrega y feedback continuo.
Evolucionar software construido mediante bases de código fuente inorgánicas hace que sea cada vez más difícil mantener el ritmo del trabajo y evolucionar el código fuente para las nuevas necesidades que requieran los usuarios.
Durante la pandemia del Coronavirus las empresas sufrieron una obligación de transformarse digitalmente… a la fuerza. Eso llevó a grandes inversiones, muchas veces apresuradas, como contratar más desarrolladores o roles ágiles.
Hoy en día, en el contexto de bajo crecimiento mundial, las empresas se están preguntando… ¿A dónde está yendo a parar toda esta inversión en tecnología? Y como existe la fractura entre negocio y tecnología, el mostrar resultados reales se hace finalmente… imposible. Los roles ágiles contratados apresuradamente están siendo de los que primero se recortan, seguidos por roles de desarrollo. No es raro ver equipos digitales disminuidos al 50% con la presión de rendir igual o mejor, o iniciativas digitales eliminadas de raíz.
Es hora de asumir que, pese al bombo y platillo de la agilidad, los graves problemas que le dieron origen siguen tan presentes hoy como ayer: ambientes laborales tóxicos, proyectos fallidos, desperdicio de recursos, impacto discutible.
Con o sin la etiqueta “agilidad” quienes estamos dedicados a mejorar la humanidad, ética, productividad e impacto real de las organizaciones tenemos una enorme labor por delante. No podemos conformarnos con placebos o videos motivadores de tres minutos.
Se requiere valor para cuestionar lo establecido, compromiso para cambiar hábitos arraigados y humildad para reconocer que no tenemos todas las respuestas. Debemos colaborar de forma radicalmente más efectiva.
Sólo así lograremos desatar todo el potencial de las personas en las organizaciones y conjuntamente encontrar soluciones sostenibles a problemas sistémicos. El futuro no puede esperar más.
La Agilidad no se puede comprar en roles o entregar responsabilidades ágiles por decreto.
Se imaginan si enviamos a un empleado a aprender karate en una certificación de 16 horas, y a su vuelta lo hacemos combatir, ¿cómo creen que le irá?. Es el mismo problema con las certificaciones exprés que se popularizaron en la Agilidad y que han logrado un océano de Scrum Masters o de Product Owners, pero con un centímetro de profundidad.
Tenemos que establecer mecanismos serios de formación y validación de desterzas en la gestión ágil es de productos, y en la facilitación de equipos ágiles. No les va a gustar a los certificadores actuales, pero la necesidad es cada vez más urgente.
Los C-Level necesitan un rol claro en esta nueva realidad.
El Corazón de la Agilidad puede dar respuesta sencilla a este dilema; el rol de los líderes es habilitar y potenciar a las personas en la colaboración, la entrega de valor, la reflexión y la mejora.
Mucho de nuestro trabajo consiste en reemplazar máquinas por personas, en vez de empoderar a las personas a realizar un trabajo más valioso y reconfortable con herramientas digitales.
¿Realmente queremos ser eliminadores de puestos de trabajo?