¿Qué es eso de la Agilidad?
Cuando nos hablan de ágil lo primero que nos viene a la mente es rapidez. Pero ágil no es veloz. Ve a la tortuga, le ganó a la liebre no por ser veloz. Es más ágil quien es capaz de ir avanzando, aunque sea paso a pasito, a quien va a toda velocidad sólo para estrellarse, en el lugar equivocado además.
Otras veces pensamos que ágil es resiliente, aguantar los embates y persistir. Pero ágil no es resiliente. Un árbol es resiliente ante el viento pero al terminar el huracán se mantiene exactamente en el mismo lugar.
Agilidad es en realidad la capacidad de cambiar de dirección, de postura, sin perder velocidad y resiliencia. Ágil es aquello que es capaz de ADAPTARSE.
Si te interesa saber más sobre lo que significa ser ágil, checa este link para más información: https://lnds.net/blog/lnds/2018/07/01/anti-agil/
Los Tres Ejes
¿Cuántas veces te ha pasado que planteas tu proyecto muy mono, haces tu plan, haces tu gantt, comienzas a desarrollarlo, y cuando vas bien avanzado, quizá terminando, tú o tu cliente se dan cuenta que no iba por ahí? ¿Al principio todo parecía miel sobre hojuelas pero resulta que ni él ni tú se dieron cuenta que el proyecto no resolvía el problema que querían? ¿Recuerdas hace un año en febrero 2020 cuando tenías esos sueños y proyectos, laborales o personales, y de repente ¡pum! pandemia y a cambiar de planes? En cualquiera de esos casos, ¿tuviste que reiniciar o cancelar el proyecto? y en todo caso ¿fue un cambio sencillo, ya ni siquiera feliz?
Un proyecto con características ágiles te puede ayudar a aguantar el embate, a adaptarte. El cambio siempre va a existir, siempre habrá que adaptarse ante mil situaciones, puede ser un bicho extraño, pueden ser las cambiantes condiciones del mercado, o puede ser que ni tú ni tu cliente tenían idea al principio y ahora que todo avanza y aterriza nos damos cuenta que no iba por ahí.
En un proyecto ágil siempre te vas a encontrar con tres componentes esenciales, que deben ser gestionados:
El Producto
Eso que se quiere construir o lograr. Sea tecnología, un proceso, manufactura, etc.
Para poder gestionarlo necesitas a alguien que se enfoque solamente en él y sus características. Llamémosle dueño del producto o product owner (PO).
La idea de lo que se va a construir puede ser muy vaga. Bueno, la chamba del PO es detallarlo lo más posible, y en lugar de tener un mega-documento con ese detalle, se debe partir en pedacitos, donde cada pedacito narre un aspectito del producto. Algo como una historia: "Cuando el Coordinador de Emprendedoras QUIERA LOGRAR esto, debe HACER aquello, y PASARÁ esto otro." Con cada detallito del producto se crean todas las historias que se crean necesarias, y las compila en un lote que podríamos llamar la reserva del producto, o backlog.
Lo importante de la reserva es que las historias estén ordenadas conforme a una prioridad: el valor que para el cliente dicha historia le da al producto. ¿Cuál es la historia MÁS valiosa? ¿Y cuál la siguiente? ¿Y la siguiente? Ya con eso, el PO va a tener el trabajo continuo y constante de reordenar la lista conforme las circunstancias lo dicten, y agregarle o quitarle historias conforme el cliente vaya viendo cómo se construye el producto. Recuerda: se vale hacer cambios SIEMPRE.
El Proyecto
Aquello con lo que vamos a construir el producto. A mi consideración es la parte más divertida de todo. ¿Has oído esa frase que dice "no se trata del destino, sino del viaje"? Es justo eso.
Quien se encarga de esta parte será un equipo de gente. Debe estar compuesto de todos los que hagan falta para construir el producto. ¿Necesitas un experto en ventas? ¿Un experto en logística? ¿Un especialista en capacitación, o en marketing y comunicación? Están dentro. Cualquier rol que se necesite para poder construir el producto deberá formar parte del equipo. El requisito solamente es que se enfoquen en el proyecto y nada más.
Y todos deben saber adaptarse (¿recuerdas que queremos ser ágiles?) Si no se adaptan, difícilmente podremos lograrlo.
Entre sus tareas primero que nada, y de manera constante, el equipo debe estimarle a cada historia del backlog el costo, o complejidad que implica construirla. Nadie más puede hacer esto, los especialistas pueden porque saben cómo hacer las cosas. El PO sabe cuánto valen para el cliente, pero sólo el equipo sabe lo que implica construirlo.
En segundo lugar construirán el producto, hablaremos de eso más adelante.
El Proceso
Por último nos falta una forma de hacer las cosas. Resulta que el proyecto NO DEBERÍA indicar cómo nos organizaremos, ni qué plan seguiremos. Asumimos que el plan, cualquiera que sea, va a cambiar y no vale la pena tener uno tan concreto, completo y detallado desde un inicio. Así que para poder operar y construir el producto a través del proyecto, lo que necesitamos es un Proceso.
Del proceso se va a encargar un Maestro, o Coach, experto en cómo ser ágiles y cómo lograr más agilidad y cómo detectar impedimentos y buscar liberarlos. Sin proceso no tenemos agilidad. OJO: no necesitamos orden, el orden lo dará por un lado el dueño del producto al elegir qué historias ir haciendo a partir de su valor, y el equipo de desarrollo conforme determina cómo construirlas, todo de manera ágil. Lo que necesitamos aquí es más agilidad.
Así que pasemos a esa parte donde el Coach debe brillar, y donde el equipo se vuelve protagonista construyendo el producto. ¿Cómo hacemos para ser ágiles, dado que no hay un plan previamente hecho del todo, ni un orden definido establecido, y el mismo producto puede cambiar de pronto?
Bienvenido al mundo de los marcos ágiles...
Marcos Ágiles
Como si de un principio zen se tratara, en proyectos ágiles el tema con el proceso es que no hay proceso. O más bien no hay uno definido, ni para cualquier proyecto, ni para un proyecto solito: el proceso puede variar a lo largo de toda su duración. El producto puede cambiar, y el proceso también.
¿Cómo se ve un proceso ágil en acción?
La agilidad se logra adaptándonos a un marco que nos da ciertas pautas a seguir... Veamos uno muy común, llamado SCRUM:
Primero que nada, y sólo para aclarar, le llamaremos SM al coach aquí, porque ese es el nombre que se le suele dar: Scrum Master.
Partimos el desarrollo en pequeños pedazos de tiempo, llamémosles carreras, o sprints. OJO: no vamos a definir qué vamos a hacer a cada sprint, eso no es ágil. Sólo definiremos lo que se hará en un sprint a la vez. Lo que no entre en el sprint que vamos a hacer se quedará en el backlog.
Vamos a hacer un avance pequeño pero valioso que sume al producto. No va a ser el producto terminado, pero va a tener valor. Y lo vamos a construir en un periodo de tiempo CORTO y 100% ENFOCADO por parte del equipo. Como si se dedicaran a correr una carrera de 100mts, no una maratón.
El ejemplo que me gusta poner aquí es el de una casa. En vez de entregar toda la casa completa hasta el final, entregamos primero el baño, luego un dormitorio, luego la cocina, luego otro dormitorio... Así sucesivamente hasta tener la casa completa. Y en cada sprint estamos entregando partes USABLES, aunque falte por tener el producto terminado.
El PO indica QUÉ se va a construir en este periodo corto de tiempo basándose en el valor y costo de cada historia y en la velocidad del equipo (la cantidad de valor que el equipo va entregando conforme pasan las carreras). Y el equipo decide el CÓMO lo hará.
Un sprint consiste de:
- Planeación, al inicio del sprint el equipo toma las historias elegidas, las descompone en tareas necesarias, estima tiempos, organiza a lo largo del sprint para construirlas. Si algo es demasiado, sale del sprint y regresa a backlog. Si sobra un hueco se puede meter algo más, y si falta se decide qué no hacer en esta ocasión. Se planea SOLAMENTE el sprint que comienza. Dividen cada historia en las partes necesarias para construirla. La historia es una meta, y ésta se divide en tareas para conseguirla. Organizan cómo ir construyendo y armando todo para integrarlo al producto que irá creciendo carrera tras carrera. Un tablero kanban es buenísimo para organizar esto. ¡PO, SM y equipo deben estar presentes!
¡En ese momento arranca el sprint! Un sprint por cierto puede durar una semana, dos, incluso tres o hasta cuatro (eso sí, lo usual son una o dos). Pero nunca más. De lo contrario perdemos la habilidad de ser ágiles. Y la duración debe definirse, cuando mucho, al inicio del sprint, antes de la planeación. - Daily, a diario, a la misma hora que definan, el equipo se reúne con SM para informarse entre ellos: ¿qué hicieron ayer? ¿qué piensan hacer hoy? ¿hay algún impedimento? SM toma nota y su trabajo será liberar impedimentos. El propósito de esta reunión es mantener a todos al tanto de cómo vamos, y detectar donde la agilidad se nos pierde. NADIE se debe enrredar en los detalles. Si la junta dura más de 15 minutos lo están haciendo mal. Los que necesiten entrar en detalles reúnanse en otro momento. Esta reunión no sólo debe ser breve, debe ser concisa. Y no importa la hora a la que suceda, mientras sea consistente durante el sprint. El propósito, además de registrar el avance que se va logrando a diario, es detectar los bloqueos para poder quitarlos del camino a tiempo.
- Review, y cuando termine el sprint se reúnen todos ¡junto con el cliente! Y le demostramos lo construido en el sprint. ¡Sí, sí! ya sabemos que no está completo, eso lo deben tener claro todos, incluido el cliente. Pero queremos que interactúe, y que nos de su punto de vista. ¿Algo debe cambiar? ¿Algo se puede ajustar? Ya de mínimo ¿le está gustando? Y terminando aprovechemos para elegir las historias que realizaremos en la siguiente carrera ¡y repetimos!
- Retro, ¿hartos de reuniones? ¡Hagamos otra! Bueno no, hagamos una pero no para trabajo. Casi. Hagamos esto para entender qué tan bien nos fue, qué tan ágiles fuimos. ¿Cómo podemos mejorar y ser más ágiles? ¿Qué cambios le hacemos al proceso que seguimos en esta carrera? ¿Qué le mejoramos al proceso? ¿Qué compromisos asume cada uno? Todo con el propósito de ser más ágiles en la siguiente carrera ¡Y no lo hagamos aburrido! Hagámoslo con una dinámica que nos permita también relajarnos. Es una reunión importante y no debe omitirse. El chiste es ser más ágiles y adaptables, si siempre hacemos lo mismo podríamos no estar listos para responder con agilidad ante el cambio. Y todos los involucrados deberían estar presentes.
¿De dónde salió esto?
El movimiento ágil surgió el año 2001, cuando un grupo de desarrolladores de software se reunieron para entender cómo hacer proyectos de tecnología de manera mucho más eficiente que con los clásicos procesos en cascada, llenos de procesos, reglas y documentación. Y enunciaron el hoy conocido como manifiesto ágil:
- Individuos e interacciones sobre procesos y herramientas.
Importan las personas y cómo se relacionan para lograr el proyecto, no tanto el proceso y cosas que se usen con un orden que pretenda ser la medicina para lograr las cosas.
- Proyectos funcionando sobre documentación extensiva.
Importa más que logremos el objetivo, el producto, en avances poco a poco que otorguen valor, a que por proceso tengamos que llenarnos de requisitos y documentos y artefactos.
- Colaboración con el cliente sobre negociación contractual.
Lo que importa es que el cliente colabore y nosotros con él, no atenernos a lo que se pudo definir en un inicio.
- Respuesta ante el cambio sobre seguir un plan.
El cambio no sólo es inevitable, es deseable. Si teníamos un plan, más vale no atenernos a él porque lo seguro es que va a cambiar.
¿Sólo para T.I?
¡Qué bonito! ¿Pero esto sólo sirve para proyectos de tecnología? ¡Por supuesto que no!
La agilidad es necesaria en muchas áreas. Y si una organización pretende tener un crecimiento exponencial, más vale entender que el cambio va a llegar cada vez más rápido. Y como dicen, es adaptarse o morir.
Los proyectos ágiles brillan sobre todo en entornos donde hay alto grado de incertidumbre (sobre lo que se quiere construir) y/o muy poco acuerdo entre las partes (clientes y constructores). Cuando hay mucho acuerdo y poca incertidumbre quédate con la cascada, no te hagas más rollos. Pero entre más caos haya es mejor ser adaptables, ¿no crees? Y si queremos ser exponenciales el caos va a venir, la incertidumbre va a ser mucha y seguramente los acuerdos serán escasos o poco sólidos. La buena noticia es que podemos construir a pesar del caos, los marcos ágiles son una manera de lidiar con él.