“Agile” parece estar sufriendo la misma suerte. Ser Agile es la nueva panacea para muchas empresas. La promesa de Agile, según entienden muchos, es que tendrán resultados más rápido. No es que esto no sea cierto, o sea todo lo que piensan obtendrán, pero pensar que esto es el beneficio de Agile es reducir un concepto muy amplio a una visión resultadista, táctica, que comoditiza una filosofía para beneficio de una visión corto-placista.
Antes de definir qué es ser Agile, miremos ejemplos de lo que no es ser Agile.- Ser Agile no es tener un listado de tareas o proyectos (priorizados o no) y llamarle Backlog.
- Ser Agile no es trocear una Gantt, planear todo de antemano y dividir el mismo mega proyecto en “Sprints”.
- Ser Agile no es cambiar la planificación del trabajo diario en el área de TI para hacerla más eficiente a nivel de gestión interna.
- Ser Agile no es hacer un app rápido pero de baja calidad, llena de bugs, que cumple los requisitos mínimos del usuario o cliente.
- Ser Agile ni siquiera es sentarse juntos alrededor de una mesa de trabajo pero no tener excelente coordinación, comunicación y alineación
Las reuniones, las herramientas, el ritmo de trabajo son actividades, técnicas de trabajo, que algunos de los aspectos tácticos de Agile. Es lo que muchos llaman «Hacer Agile». De hecho, son guías, aspectos, herramientas de alguna metodología o marco de trabajo en concreto de Agile (como por ejemplo, Scrum, Kanban, XP, etc).
Cuando una implementación de Agile se enfoca en lo táctico, estamos dejando de lado lo que es ser Agile de verdad.
¿Qué es ser Agile?
En 2001, 17 desarrolladores se juntaron en Utah, USA, para buscar una metodología más “ligera”, que les permitiera adaptarse a un contexto cambiante. El resultado fue el Manifiesto Agile y la formación de una “Alianza Agile” que se dedicó a evangelizar esta nueva filosofía de trabajo.
El Manifiesto Agile tiene los siguientes principios fundamentales:
- Individuos e interacciones sobre procesos y herramientas
- Software de trabajo sobre documentación completa
- Colaboración del cliente sobre negociación de contrato
- Responder al cambio sobre un plan rígido
Jim Highsmith, uno de los participantes de esa reunión original y firmante del Manifiesto, explica que los desarrolladores que formaron la Alianza (y el Manifiesto) tenían una visión común, “un conjunto de valores compatibles (…) basados en la confianza y el respeto mutuo y promoviendo modelos organizacionales basados en personas, colaboración y construyendo los tipos de comunidades organizacionales en las que nos gustaría trabajar.”
También explica que “los Metodólogos Ágiles realmente tratan de cosas «blandas”, de entregar buenos productos a los clientes operando en un entorno que considera a las personas lo más importante”.
Del manifiesto Agile se desprenden 12 principios clave:
- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de (software con) valor.
- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
- Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
- El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
- La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
- A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
- Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
- Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
- El software funcionando es la medida principal de progreso.
- Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
- La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
De los 12 principios, 7 (que he juntado al principio) son universales y aplicables al mundo online u offline. Y todos ellos tratan de valores y cultura, donde las personas están al centro, e importan más que los resultados finales (que también son muy importantes, pero nunca a coste de las personas). Y hablando de resultados finales, es importante destacar que Agile está enfocado en crear buen producto como resultado de un proceso (el “outcome”, como se le llama en inglés), en vez de enfocarse en entregar algo (“output”) (a menudo a cualquier coste)
La visión
Adoptar la visión Agile implica un cambio cultural profundo. Implica dejar de intentar controlar y definir todo desde el principio, dejar de trabajar en silos, de funcionar en base a relaciones jerárquicas o guiados por un resultadismo casi obsesivo.
Agile no es una metodología; ser Agile es tener una visión consensuada, que se centra en cómo las personas trabajan, se relacionan y cómo consiguen resultados.
La estrategia
Una vez hemos consensuado esta visión, para trabajar de manera agile («hacer Agile») necesitaremos decidir qué marco de trabajo concreto adoptar. Esta es una decisión estratégica que hará realidad la visión.
Ejemplos de marcos de trabajo (y vaya con la confusión entre “metodología” y “marco de trabajo”…) son
- Scrum
- Kanban
- Extreme Programming
- Dynamic System Development (DSDM)
- Feature Driven Development (FDD)
- Agile Project Management (APM)
- Lean Kanban, Lean Startup (ya hablaré de Lean en otro post 😉 )
Sin embargo, la adopción de una metodología (o marco de trabajo) no es pintar por números. No hay una fórmula mágica universal. Más allá del plano “blandito” (el cambio cultural, valores, etc –que de por sí es la base y lo más importante de ser Agile), tenemos que entender que no hay ningún modelo perfecto, una talla única que se implemente y ya. Cada empresa, cada equipo es diferente (en cuanto a cultura, conocimiento, experiencia, producto, mercado, etc).
Tomemos como ejemplo Scrum, que es uno de los marcos de trabajo Agile más populares. Los creadores de Scrum, Ken Schwaber y Jeff Sutherland (que escribieron y mantienen la “Guía de Scrum”) definen Scrum como: “un marco de trabajo a través del cual las personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el máximo valor.
Luego aclaran:
“Scrum es un marco de trabajo compuesto de procesos que se ha utilizado para gestionar el trabajo de productos complejos desde principios de los años 90. Scrum no es un proceso, una técnica, o método definitivo. Todo lo contrario, es un marco de trabajo donde se pueden emplear un conjunto de diferentes procesos y técnicas.
El plano táctico
Una vez tengamos claro el camino que tomaremos para alcanzar la visión, podemos (finalmente) pasar al plano táctico y definir actividades, artefactos, herramientas, etc.
No es suficiente con hacer un curso (en Scrum, Kanban, XP, etc) y ya eres Agile. A lo sumo, sabrás los ritos, artefactos, actividades y herramientas de ese marco de trabajo. Cuando se deja fuera la visión y la esencia de Agile, y se adoptan sólo las herramientas, artefactos, ritos, actividades de Scrum, o Kanban, etc se adopta lo que se llama “Fake Agile” (o “Waterfagile” o “Agilefall”).
Adoptar las herramientas, ceremonias, etc, es adoptar sólo la táctica. Y como escribió Sun Tzu en “El Arte de la Guerra”, “La estrategia sin táctica es la ruta más lenta hacia la victoria. La táctica sin estrategia es el ruido antes de la derrota”.
Desafortunadamente, muchas empresas tienden a enfocarse en lo táctico, porque es más tangible, medible. Exigen resultados tales como velocidad de entrega, rentabilidad, ventas, etc y las actividades en el plano táctico dan (o deberían dar) resultados rápidos y visibles (aunque no sean buenos resultados).
Cuando les hablas a estas empresas de cambio cultural, la conversación tiende a cambiar de tono. “Bueno, si ya veremos si de caso, pero dame resultados primero para probar que funciona. Es que lo otro, todo lo “blandito”, es muy complicado y ahora no están las cosas para hacer grandes cambios”.
Quedarse en el plano táctico es querer el cambio sin querer cambiar (o que me cambien). Es resultadismo cortoplacista y conservador, agitando el nombre Agile como una varita mágita, la misma varita con la que se compró un diseñador UX para que arreglara la UX de la güeb.
Si el objetivo de una implementación “Agile” es simplemente mejorar la velocidad de entrega, aumentar profitabilidad y ver los entregables de un proyecto más –a menudo a costa del bienestar de los integrantes de los equipos Agile, ignorando todo lo “blandito”, el aspecto cultural– entonces no somos Agile. Si queremos de verdad tener los beneficios de Agile, entonces deberemos comenzar el camino para ser Agile de verdad.
Ser Agile de verdad
Ser Agile es un proceso de aprendizaje que nunca acaba, donde debemos cambiar continuamente para adaptarnos a cada equipo, situación y estadio de nuestro proceso de aprendizaje. Es un camino que empieza por la visión de cómo trabajar.
Claro está que la adopción de algo nuevo (sea una metodología, un producto, un servicio) no se puede hacer de golpe, en un día. Es un proceso, y si somos Agile de verdad, tendremos siempre la visión presente. Cuestionaremos el marco de trabajo. Querremos hacer iteraciones e ir expandiendo y consolidando a medida que medimos y aprendemos. Pero en todo caso, hay que tener desde el principio una convicción clara que la visión Agile es la que queremos, aunque lleve tiempo (sobre todo en empresas muy grandes).
¿Qué puedes hacer tu?
Siempre podrás hacer algo para ser agile, porque Agile va de personas y el primer cambio es el cambio de mentalidad que hacemos cada uno de nosotros.
Si eres el fundador, piensas fundar o trabajas en una startup pequeña, si eres un Product Owner, un project manager, un Head of UX, un diseñador o un líder funcional (marketing, comercial, etc), puedes comenzar a ser Agile si comienzas por adoptar la filosofía Agile a nivel de personas, comunicación, respeto. Puedes plantear una visión para tu equipo que sea Agile en esencia.
Como este post es muy (¿demasiado?) simplificado, espero que al menos sirva como punto de partida para picar tu curiosidad, salir e investigar más. Hay suficientes recursos gratis online, y libros, y videos, y cursos para aprender más sobre cada marco de trabajo (como por ejemplo,
Si sabes inglés, puedes visitar la sección de recursos de la web de Scrum.org, donde tienen recursos excelentes. (Pero recuerda: aprender las técnicas de Scrum no te hará ser Agile; simplemente te ayudará en el camino.)
Recomiendo también la presentación) de Rashina Hoda sobre “Being Agile and Doing Agile” (video en inglés, 37 minutos Rashina ha pasado más de 12 años investigando los aspectos humanos y sociales de Agile, y explica mucho mejor esto de Ser Agile (en vez de Hacer Agile).
Finalmente, y como parece estar muy de moda (aún), si tu empresa o tu tenéis pensado “copiar el modelo Spotify”, te invito a leer esta entrevista donde queda bastante claro que no existe un modelo Spotify.
Si quieres ser Agile de verdad, el camino comienza hoy, ahora, contigo mismo.