Agile Basics
Si bien la agilidad tiene su origen en el mundo del software (Manifiesto Ágil, 2001) su impacto ha sido tan notorio que, a día de hoy, ya ha revolucionado la forma de trabajar de miles de organizaciones de todos los sectores. ¡Y no nos extraña!
Tras más de diez años funcionando con un mindset ágil, en Runroom tenemos una cosa clara: no volveríamos atrás.
Agile es un concepto paraguas que se refiere a un método de trabajo. La palabra método viene de los términos griegos Meta (μετα), que significa «más allá», y Hodos (ὁδός), que significa «camino». Así pues, un método no es otra cosa que el camino a seguir para ir más allá.
¿Cómo funciona? Desarrollo iterativo incremental, la guinda del pastel en Agile
Aunque no es la única, el desarrollo iterativo incremental es una pata importantísima en el mundo de las metodologías ágiles y connatural a la forma que tenemos de trabajar en Runroom. ¿Cómo funciona?
Crear o desarrollar un producto de forma iterativa e incremental consiste en ir complejizando y perfeccionando ese producto en cada una de sus entregas (incrementarlo) a la luz del feedback que se obtiene de su testeo (iterarlo).
Trabajando de este modo, obtenemos un producto funcional desde el comienzo, potencialmente lanzable, que cada día se vuelve más usable y adaptado al contexto para el que fue concebido.
Cómo organizar los ciclos de entregas dependerá de la casuística del producto a desarrollar y de lo que mejor se adapte a la forma de trabajar de los equipos.
Después de años de ensayo y error, a nosotros nos funciona entregar valor al cliente —producto potencialmente publicable— en ciclos de dos semanas (sprints), que a su vez se componen de ciclos de una semana de trabajo interno.
¿En qué consisten las metodologías ágiles?
¿Dónde nos lleva el camino del Agile?
Cada organización concibe la agilidad de una manera distinta, pero si hay algo esencial a las metodologías ágiles es que todas ellas ponen el foco en entregar valor al cliente de una forma concreta: temprana y frecuente.
Las variables ‘momento’ y ‘frecuencia’ de la entrega de valor son lo que distingue a las metodologías ágiles del modelo tradicional en cascada:
Sucede que, no pudiendo aportar valor hasta la fase final del proceso, las metodologías en cascada son incapaces de aprender del feedback del usuario hasta ese momento. Esto acarrea, como mínimo, dos problemas:
- Menor fit. La solución a la que se llega es menos adecuada a la necesidad real del usuario.
- Waste, rework. Cualquier cambio a partir del momento de la entrega de valor es costosísimo porque el producto tiene que volver a pasar a través de toda la cascada.
Entonces, ¿qué tenemos que hacer para conseguir una entrega temprana y frecuente de valor, si parece ser claramente más eficiente y optimizada?
Outcome del desarrollo iterativo incremental
¿Qué conseguimos con un desarrollo iterativo incremental?
-
Maximizar la entrega de valor al cliente: Testear y recibir feedback del usuario en tiempo real nos permite matizar la definición del producto que necesitamos, maximizando así el valor que le entregamos al cliente.
-
Minimizar costes de desarrollo: Entregar valor de forma iterativa e incremental minimiza los costes derivados de incorporar el feedback ya que, al no tener que esperar hasta el final del proceso, acortamos los ciclos de rediseño y despliegue.
- Reducir el time-to-market: Disponer de versiones inacabadas pero perfectamente funcionales del producto supone poder lanzarlo mucho antes, obteniendo, así, una ventaja competitiva.
- Disminuir riesgos de sobre-desarrollo: Teniendo en cuenta que alrededor del 60% de las funcionalidades del software manufacturado nunca llegan a utilizarse, otra ventaja importante del desarrollo iterativo incremental es que nos permite parar de desarrollar (y, por ende, de invertir) en cualquier momento, evitando, así, gastar recursos innecesarios.
El alcance de las funcionalidades se gestiona de forma dinámica, lo que asegura un encaje óptimo entre alcance, precio y tiempo ya que el cese en el desarrollo del producto lo marca el haber alcanzado suficiente retorno de valor y no un calendario ajeno al contexto real.
Esta es la pinta que tiene el desarrollo iterativo incremental de un producto organizado en sprints de dos semanas:
Desarrollo Iterativo Incremental: un case
En el Case Stooa, desarrollo Agile de una herramienta de fishbowls explicamos el proceso de research e iteración que nos permitió convertir una intuición en realidad y dar vida a Stooa: el primer fishbowl online del mercado.
Requisitos del desarrollo iterativo incremental
Son conditio sine qua non para un desarrollo iterativo incremental:
-
Cross-funcionalidad: Una entrega temprana y frecuente de valor requiere colaboración y romper los silos funcionales; que todas las disciplinas trabajen juntas para conseguir una meta común. Se trata de que los equipos estén alineados en torno a objetivos de negocio (entrega del máximo valor al cliente final) y no en torno a objetivos departamentales, con su consiguiente delegación de responsabilidad.
- Autonomía: Desarrollar un producto de forma iterativa incremental requiere equipos auto-gestionados que no dependan de decisiones externas jerarquizadas, que podrían bloquear y/o fragmentar el flujo de trabajo. Para ello, es clave descentralizar la toma de decisiones y potenciar la autonomía de los equipos, quienes, en tanto que expertos, son los que mejor conocen cómo desarrollar el producto.
- Mentalidad Kaizen, cultura cimentada en acciones: Kaizen (改善) es una palabra de origen japonés compuesta por dos vocablos: kai (改) que significa «cambio», y zen (善) que quiere decir «beneficioso». Para un desarrollo iterativo incremental en el que el producto evoluciona constantemente, necesitamos que el cambio sea bienvenido; necesitamos mentalidades Kaizen orientadas al aprendizaje y la mejora continua. Para ello, será clave dotar a la organización de agilidad (Business Agility) y crear una cultura organizacional cimentada en acciones y comportamientos que subrayen la excelencia, el aprendizaje y el crecimiento profesional y personal de los empleados. No basta con decorar el estudio escribiendo nuestros valores en las paredes; hay que dedicar tiempo efectivo a la mejora.
Un ejemplo de buena práctica al respecto son las retrospectivas periódicas: ¿Qué ha funcionado? ¿Qué bloqueos han surgido? ¿Cómo estamos colaborando?... Liturgias que nos ayudan a pulir el proceso y a introducir pequeños cambios incrementales en el workflow a lo largo del tiempo.