¿Es Agile una moda o tendencia?

En esta entrada, debatiremos las siguientes cuestiones, con las que contextualizar el uso de Agile en la empresa, sus principales ventajas e inconvenientes.

 

• • ¿Consideramos que Agile sólo es aplicable a un entorno de tecnología?

• • En un marco de trabajo como SCRUM, por ejemplo, ¿cuál es la principal utilidad o ventaja de aplicar Agile?

• • ¿Agile puede o debe formar parte de la cultura de la empresa?

Objetivos: Determinar si Agile es solo un conjunto de reglas o puede formar parte de la cultura de las organizaciones.  

El Manifiesto Ágil nació en un ámbito de tecnología (Desarrollo del Software), y creo que es donde mayor aceptación y uso tiene en la actualidad, aunque conozco muchas empresas que desarrollan software que todavía no lo han aplicado – o bien les va de fábula con su metodología de toda la vida, o bien no se han interesado por ver si “moverse a Agile” les ayudaría a ser más eficientes. Aunque desconozco los otros sectores, creo que ciertos conceptos Agile se podrían aplicar y serían válidos. Por ejemplo, creo que Scrum está claramente enfocada a equipos que desarrollen productos, sean de software o no. Para otro tipo de equipos, por ejemplo, de Operaciones o Soporte, me parece mucho más válido Kanban (contempla un factor de imprevistos o “carril rápido”, no se apoya tanto en la planificación, es más para organizar el día a día y no tiene iteraciones). Paradigmas ágiles usados en IT como Lean provienen del sector industrial automovilístico (Toyota) y sus principios como optimización de procesos, reducción del desperdicio, mejora continua o producción “Justo a Tiempo” se pueden aplicar a sectores más Operativos, de Producción o Industriales.  

 

Creo que, en el ámbito IT, sí que ha acabado siendo una especie de “moda o tendencia”, sin que eso signifique algo negativo. Como todos los avances técnicos que han supuesto un punto de inflexión por su innegable utilidad o practicidad, Agile (y en concreto su marco de trabajo más conocido, Scrum) se ha ido imponiendo, sea porque sus impulsores dentro de la empresa han sido unos early-adopters (o bien, unos frikis) agilistas, sea porque los cantos de las bondades de ser ágil han llegado a oídos de alguien con poder para decidir aplicarlo (CIO, Director de IT, etc.).

La verdad es que creo que la mayoría de los que hemos acabado haciendo Scrum o Agile, ha sido por esta segunda vía (no conozco a nadie que lleve más de 10 años haciendo Agile, aunque haberlos, haylos), así que podríamos decir que sí es claramente una tendencia, pero (a mi parecer) ésta se ha impuesto por razones prácticas obvias. Creo que es la alternativa perfecta para desarrollos de alta complejidad, desarrollados por un equipo de tamaño medio, y con necesidades multidisciplinares (hoy en día, la mayoría de los proyectos o productos necesitan de un equipo que domine múltiples facetas: front-end, back-end, análisis funcional, bases de datos, rendimiento…).  

 

Al final, la mayoría de los pilares de Agile, Scrum o DevOps (concepto primo-hermano de Scrum, que va más allá pero que se apoya en conceptos similares) son de sentido común: potenciar la comunicación, la co-responsabilidad y auto-gestión del equipo, el compromiso de este para con su producto / servicio, ayudar a estimar mejor los proyectos de IT (algo harto complicado, por eso Scrum propone hacerlo mediante el paradigma del divide y vencerás), entregar incrementos de valor real (working software) de forma contínua y recurrente (los despliegues no tienen que ser necesariamente al final de cada sprint, pueden ser más frecuentes –en el caso, sobretodo, de bugs, o de otras funcionalidades que se deciden pasar a producción “cuando estén listas”- o también pueden serlo menos por política de empresa, al final esto es un tema de delivery… pero el equipo está constantemente finalizando backlog ítems, y por tanto entregando valor), se va mejorando y adaptando el producto de forma iterativa y colaborativa junto al cliente, se escucha el feedback constante (con el cliente, al menos al final de cada sprint; con los miembros del equipo, en las dailies y de forma constante), se hacen retrospectivas para mantener la sierra afilada (o mejorar continuamente),… en definitiva, es una mecánica de desarrollo que sirva para que los miembros del equipo estén más implicados y produzcan software de mejor calidad y más valor para sus clientes / usuarios.  

 

¿Desventajas? Las hay: el tiempo de aclimatación a Scrum suele ser largo (en mi experiencia, alrededor del año para engrasar automatismos y ganar empaque como equipo), ya que a mucha gente le cuesta cambiar el mindset o forma de trabajar que lleva arrastrando de hace tiempo. Muchas personas nunca se adaptan a la duración de los rituales (reuniones de Sprint Planning, Review o Retrospective) y las consideran una pérdida de tiempo. Normalmente es gente más bien introvertida, que no quiere abrirse a escuchar en qué trabajan los demás (dentro de un mismo producto o servicio) y que prefieren “trabajar” a perder tiempo hablando, y difícilmente les convencerás que eso, a la larga, es beneficioso para el trabajo en equipo.  

Para que el Scrum funcione bien, hay que ceñirse bastante a sus reglas, pues si lo desvirtuamos mucho (sobretodo esos puntos clave que hay que mantener) acabaremos por  no hacer las cosas del todo bien, haciendo algo que ni es Scrum, ni es otra metodología. En mi anterior empresa, lo acabamos haciendo así, y constantemente estábamos readaptando conceptos (incluso después de más de 2 años de Scrum), así que se perdía tiempo en gestión, y debido a esos reajustes, de vez en cuando había altibajos de motivación en el equipo. Otra de las cosas que Scrum dice es que, para que sea productivo, un individuo debe pertenecer el mayor tiempo posible seguido a un mismo equipo (esto es así porque Scrum se basa en la confianza entre las personas). Esto, a nivel empresarial, puede verse como un desperdicio de recursos, al no poder reasignar “expertos” a otros proyectos. De hecho, Scrum es un framework orientado a productos, no a proyectos. Esto lo hace ideal si trabajas en un único producto (ejemplo: Spotify), con un único backlog que priorizar y gestionar. Pero el problema es que en la realidad las empresas trabajan con multitudes de proyectos, de multitudes de productos, y ahí Scrum por sí mismo deja de funcionar, siendo necesario escalarlo aplicando otras técnicas más sofisticadas y complejas como SAFe (Scaled Agile Framework), LESS (Large Scale Scrum) o Scrum de Scrums (de Scrums…). Esto cambia mucho el idílico equipo Scrum de 8 miembros y repito, aumenta la complejidad a niveles que provocan muchos quebraderos de cabeza (quizás, en mi experiencia, la mejor solución sea el Scrum de Scrums, pero requiere mucho tiempo en gestión y hay que hacerlo bien).  

 

Terminando con las desventajas, y enlazando con las preguntas no contestadas: si la alta dirección de la empresa no se da cuenta y promueve que es toda la organización, y no sólo los equipos IT, que se debe agilizar de un modo u otro, Agile no triunfará en ninguna empresa. Eso es así porque lo dicen todos los Agile Coaches y Scrum Masters, pero sobretodo porque lo he vivido, sólo hace falta aplicar Scrum en IT en una organización jerárquica tradicional, para darse cuenta de ello. Ejemplo: en Scrum existe el Product Owner, que es el DUEÑO DEL PRODUCTO, quien decide qué se hace con el producto, qué y cuándo (el cómo, entendido a nivel de implementación, lo decide el equipo). Bien, pues como podéis imaginar, en una empresa tradicional, el Product Owner de Scrum suele ser una persona del departamento de IT (primer error, debería ser alguien experto en el producto, ¿de marketing quizás?), que debe interactuar con todo un equipo de marketing, con los Jefes de Producto (que son Jefes pero no Owners), con Comités de Dirección, Consejos Administrativos o con usuarios finales, para dilucidar cuál es el Roadmap del Producto, a partir del cual va a extraer un Product Backlog, y priorizar cada uno de los Backlog Ítems (funcionalidades del producto). Esto lo convierte en un proxy Product Owner, un intermediario, o marioneta, de otros con más poder de decisión.  

 

El equipo Agile debería tener poder sobre todas las decisiones del producto (no sólo las técnicas). De nuevo, se topan con jerarquía no Agilizada que interviene en su producto, y que les genera bloqueos, tiempos de espera de decisiones o información (waste o desperdicio), alto management que les cambia las reglas del juego cuando la empresa cambia el rumbo… En resumen, el principal problema de Agile, según mi experiencia, es que es visto como una moda de desarrollo IT y no como una filosofía integral de empresa. Por eso creo que es tan importante cambiar primero la cultura antes de intentar aplicar Agile (y por eso lo hemos estudiado en este MBA), si no, es imposible agilizarte a no ser que seas una startup, tengas una jerarquía muy plana, o apliques Agile sólo a una parte pequeña y autosuficiente de la organización.  

 

Como anécdota, en un congreso de Agile celebrado en 2018 en Madrid me explicaron que Telefónica I+D, empresa tradicionalmente jerárquica, había agilizado a uno de sus equipos para un proyecto determinado (organizado como equipo Scrum, autosuficiente, eliminado la mayor parte de la burocracia, focalizado en resultados y dadas todas las facilidades). Ese piloto de Agile salió tan bien, que pasado un tiempo su responsable fue nombrado director de toda la empresa (dept. I+D de Telefónica), y cuando llegó a director, eliminó la burocracia y jerarquía imperante para pasar a organizar toda la empresa en equipos ágiles. Esto normalmente no se puede hacer, y por tanto, la implantación de Agile es mucho más complicada.  

 

En definitiva, Agile no son unas reglas, tampoco un marco de trabajo (Scrum sí lo es), es un enfoque de producción de valor que normalmente se considera ligado al desarrollo de software, pero que en la actualidad tiene suficiente madurez como para ser probada, aplicada, y adaptada, a muchos tipos de organizaciones que quieren optimizar la producción, la calidad, acercarse al cliente acortando las entregas, y en definitiva mejorar su operativa. Para ser Ágil, una empresa debe empezar cuestionándose la forma cómo hace las cosas desde arriba (alta dirección) hasta abajo, y cambiar los elementos culturales necesarios para fomentar la cultura colaborativa que promulgan las metodologías ágiles.

Roger Villas es Agile Coach, Scrum Master y Product Owner certificado por entidades como Scrum.org, Scrum Alliance, Agile Coach Alliance, European Scrum y DevOps Agile Skills Association.