La revista profesional sobre tecnología y transformación digital
agile
20 años del Agile Manifesto

Sandra González Díaz

Certified ScrumMaster (CSM)

20 años del Agile Manifesto

Cada vez oímos más palabras como Agile, Scrum, Kanban o lean. Llevan con nosotros mucho tiempo, si bien es cierto que, a raíz de la necesidad de digitalizarse de muchos sectores acelerada por la reciente pandemia, se vhan vuelto más populares. En este artículo se explican las distintas formas de trabajar ‘ágiles’ tras cumplirse 20 años del manifiesto Agile.

Agile o lean son términos que tienen una base en la cultura japonesa y que se basan en mejoras continuas. La palabra Kaizen (改善) significa ‘mejora’, un cambio beneficioso que se alcanza paso a paso. El vocablo se forma uniendo dos conceptos: ‘kai’ (cambio) y ‘zen’ (bondad).

La necesidad de adaptarse a un entorno cambiante con rapidez hace que adoptar una forma de trabajar Agile o ágil, sea la más adecuada no solo para sobrevivir, sino para adaptarse de forma natural a los cambios.

Una clara definición de este entorno cambiante es el término VUCA, del inglés ‘Volatility, Uncertainty, Complexity and Ambiguity’: volatilidad, incertidumbre, complejidad y ambigüedad. El acrónimo VUCA se atribuye al ejército de los Estados Unidos y surge como una definición del mundo resultante tras el fin de la Guerra Fría. Sin embargo, en las últimas décadas, muchas organizaciones han incorporado este término en su estrategia empresarial, y refleja la realidad vivida durante la pandemia de los últimos meses.

La necesidad de adaptarse a un entorno cambiante con rapidez hace que adoptar una forma de trabajar Agile sea la más adecuada

20 años de Agile
Agile no es algo moderno ni reciente: esta forma de trabajar, basada en una serie de principios y valores, fue formalizada hace 20 años en Utah, EE. UU., a través del Agile Manifesto.

Agile surge en el desarrollo de software pero, sin embargo, en la actualidad se ha visto su valor aplicado al desarrollo de otro tipo de productos y se ha adoptado en gran variedad de industrias. Se hace hincapié en las personas, se valoran las entregas incrementales del producto, y estas se inspeccionan asegurándonos de que los continuos cambios y mejoras se alinean con las necesidades (a veces cambiantes) del negocio. De esta forma, potenciamos la mejora continua y se maximiza el valor de la entrega final.

La documentación es un claro ejemplo. Estos principios no implican que debamos obviar la misma, sino que no ha de ser una barrera, y hemos de limitarnos a aquella estrictamente necesaria o que aporte un valor añadido.

Agile no es una metodología per se, sino una mentalidad, actitud o forma de trabajar que se basa en el empirismo

Cuándo usamos Agile
para un desarrollo de producto? No siempre. En todo momento podremos basar nuestra cultura corporativa en Agile, valorando las personas y la voz del cliente final, así como generando un entorno que permita una rápida adaptación al cambio.

Sin embargo, recurriremos a una gestión de proyectos tradicional o ‘waterfall’ (en cascada) cuando no se esperan variaciones sobre los requisitos del proyecto y el objetivo final esté totalmente claro, es decir, existe un claro ‘blueprint’ (un plan detallado).

Agile no es una metodología per se, sino una mentalidad, actitud o forma de trabajar que se basa en el empirismo. Aprendemos de la experiencia y de la observación de los hechos. Es por tanto importante usar una aproximación Agile cuando desarrollamos un producto por primera vez, cuando queremos desarrollar algo; pero la incertidumbre sobre cómo llevarlo a cabo, o cómo materializar nuestra idea en un producto final es elevada.

Un ejemplo claro de gestión tradicional de proyectos o en cascada sería por ejemplo la sustitución de un equipo que se ha estropeado por otro que cumpla las mismas condiciones o donde existe un claro ‘blueprint’: tenemos un buen conocimiento del mismo, claros requisitos, tolerancias, etc. Es sencillo pensar inicialmente sobre todas las fases de principio a fin del proyecto de forma secuencial, comenzando con las fases de análisis y diseño y terminando con las de prueba y puesta en marcha. Se prioriza un alcance completo de todos los requisitos, y la interacción con el cliente por norma general se limita a diferentes ‘milestones’ o hitos.

En caso de tener que diseñar un producto del que tengamos un alto desconocimiento, un enfoque Agile sería lo más adecuado. En este caso se priorizarán aquellas funciones que aporten más valor, se harán entregas incrementales (y que funcionen) al cliente, y se capturará de manera continua su feedback de cara a mejorar el producto y adaptarlo a las necesidades. En este caso entregaremos al cliente valor de manera temprana, antes de tener el alcance completo. Los cambios son bienvenidos en cualquier momento del desarrollo, y en muchas ocasiones necesarios para el éxito del mismo. Por tanto, la interacción con el cliente se requiere a lo largo de todo el proyecto o desarrollo de producto y no solo en hitos puntuales.

Herramientas para trabajar Agile
Una vez nos hayamos decidido a trabajar de una manera Agile o ágil, existen diferentes herramientas que podemos utilizar. Cabe destacar que trabajar de forma Agile no implica entregar rápido, sino adaptarse rápidamente al cambio y entregar valor antes.

Una primera y sencilla aproximación para introducir Agile en nuestros equipos es emplear Kanban, palabra también con raíces en la cultura japonesa: viene de ‘kan’ 看 que significa símbolo, y ‘ban’ 板 que significa pizarra.

El sistema Kanban se crea en Toyota en la década de los 50 como un plan de mejora necesario en la producción de automóviles. En su creación se utilizaban tarjetas para señalizar los procesos y las materias primas. De ahí el nombre de ‘Kanban’, que en japonés significa ‘registro visual’ o ‘tarjeta’.

Kanban establece una forma visual de poder ver el progreso de nuestras actividades en una pizarra. Tradicionalmente estas se ven en factorías, o en oficinas con tablones llenos de post-its, pero hoy en día existen multitud de herramientas en línea para facilitar el uso de las mismas con equipos en remoto, o con presencia en distintos lugares.

Scrum
Scrum es quizás el marco más famoso dentro de Agile. También es una formación en rugby para volver a poner en juego la pelota, de la que toma el nombre.

Se organiza de forma iterativa en torno a sprints (periodos inferiores a un mes, típicamente una, dos, tres o cuatro semanas) y se basa en la guía Scrum o Scrum guide disponible online. Esta guía ayuda a los equipos a generar valor a través de soluciones adaptativas para problemas complejos.

Fuente: scrum.org

 

Conceptos básicos de Scrum
Scrum se basa en el empirismo y una forma de pensar lean (eliminando lo superfluo). Esto implica que el conocimiento viene de la experiencia y las decisiones se toman basadas en lo que observamos: aprendemos durante el desarrollo de nuestro producto. La forma de pensar lean hace que eliminemos aquello no esencial y nos centremos en lo importante (escuchando la voz del cliente).

Scrum es simple, pero, como dicen sus creadores, difícil de ‘masterizar’. En este tipo de proyectos no existe la figura tradicional del jefe o jefa de proyectos. Aparecen dos nuevas figuras: el/la Scrum Master y el/la Product Owner como parte del equipo Scrum junto al resto de desarrolladores.

La figura de Scrum Master se encarga de que Scrum se implemente acorde a la guía Scrum, facilitando los distintos eventos necesarios y creando un entorno en el que:

  1. El Product Owner ordena el trabajo necesario (por prioridades) en el product backlog.
  2. El equipo Scrum escoge una parte de ellos y lo convierte en una entrega incremental al final del proyecto.
  3. El equipo Scrum y las partes interesadas inspeccionan el resultado ylo adaptan para el siguiente sprint.
  4. Se repite cíclicamente.

 

El Product Owner es el dueño del product backlog (lista ordenada de tareas a llevar a cabo), comunica un objetivo claro (product goal) y se encarga de que las necesidades del cliente o de los stakeholders estén reflejadas en el producto.

Scrum se organiza en torno a una serie de eventos que se explican en detalle en la guía Scrum y que se representan en la imagen.

Por último, pero no menos importante por ello, en Scrum se definen 3 artefactos:

  • El product backlog o la pila de actividades ligada al producto, así como un objetivo.
  • El sprint backlog o la pila de actividades que se lleva a cabo durante el sprint, así como el objetivo del sprint.
  • Y  el incremento, una entrega incremental y aditiva a las entregas interiores que nos acerca al objetivo final.

 

¿Es Agile por tanto la nueva forma trabajar? No, ya lleva oficialmente años con nosotros, y aporta valor proyectos complejos y rodeados gran incertidumbre.

Referencias

  • VUCA – Wikipedia, la enciclopedia libre
  • Agile Manifesto 20th Anniversary (scrumalliance.org)
  • Manifesto for Agile Software Development (agilemanifesto.org)
  • ¿Cuál es la metodología más adecuada para tu proyecto? (deloitte.com)
  • Filosofía Kaizen: cómo mejorar continuamente en una empresa | APD
  • Historia del Kanban I Tormetal I Fijaciones y Tornillería
  • History of Kanban | Kanban Tool
  • The Scrum Guide
  • Scrum (rugby) – Wikipedia, la enciclopedia libre

 

Comparte
Compartir en linkedin
Compartir en facebook
Compartir en twitter
Compartir en whatsapp
Compartir en telegram
Compartir en email