La forma más fácil de ejemplificar el movimiento Ágil es pensar en un helado, no por lo fresco y frio sino porque viene en capas y sabores y a todo el mundo le encanta :)
La base del cono de los sabores agiles reside en toda la teoría que trae consigo el Toyota Production System que luego evoluciono hacia el Toyota Way. Subiendo un poco más hacia arriba vemos que lo anterior dio origen a la escuela de pensamiento Lean que Mary and Tom Poppendiek magistralmente plasmaron en su propuesta de Lean Software Development[1].
Lean fue uno de los puntos de inspiración para la redacción del Manifiesto Ágil[2]. Este manifiesto ha sido leído, consultado y citado en innumerables publicaciones. Sin embargo, por si solo el manifiesto no es algo que pueda ponerse directamente en la práctica.
De hecho tanto Lean como Agile son en esencia herramientas de razonamiento[3] que permiten observar, pensar y actuar de cierta forma. Por ejemplo el Lean sugiere principios como eliminar desperdicios[4] que lo que hacen es colocarnos en un estado mental predispuesto para identificar tareas que no contribuyan directamente a la generación de valor en el producto-desperdicio y que por tanto deban ser eliminadas.
En consecuencia alguien podrá decir “yo pienso agile o yo pienso lean” pero no podrá decir “yo implemento agile o yo implemento lean”. La diferencia entre el pensar y el hacer es lo que separa el cono de los sabores del helado.
El primer sabor es XP (eXtremme Programming[5]) y como en la figura es el sabor sobre el cual se apilan los demás. XP aglutina un conjunto de prácticas de ingeniería pensadas y orientadas totalmente al desarrollo de software. Consecuentemente las practicas de XP son cosas de las cuales no se puede (ni debe) prescindir en cualquier proyecto de desarrollo de software.
Me encanta hacer la analogía entre XP y un auto de F1 que fue construido con un único propósito: correr lo más rápida y efectivamente posible. A un F1 no es posible (bueno posible si pero peligroso :)) recortarle piezas; ya es una joya de ingeniería en sí que tiene lo mínimo necesario para correr. Similarmente XP es una obra maestra de buenas prácticas que deben existir (insisto todas) en un proyecto de software. XP ya es ligero como es, no hay necesidad de recortarle nada. En este sentido XP es el más prescriptivo de los sabores agiles.
El siguiente sabor es Scrum[6] que se concibió como un marco de trabajo[7] ligero que sugiere (no impone) roles, artefactos y ceremonias. Scrum es un marco de trabajo no necesariamente asociado a desarrollo de software, de hecho es tan flexible que puede ser adaptado a otros dominios de aplicación. Un ejemplo interesante ocurre en mi organización donde se está usando Scrum para impartir cursos de inglés.
Scrum formalizo-y porque no mejoro-algunas de las buenas prácticas agiles que existían desde hace tiempo como iteraciones y user stories. Una de las grandes ventajas-o desventajas como quiera verse-es que Scrum tiene detrás una organización sin fines de lucro: el Scrum Alliance[8] que es especialmente activa proporcionando entrenamientos y certificaciones.
La cereza sobre el helado es kanban[9] que es una gran mejora sobre el taskboard recomendado por Scrum.
Helado sin cono
¿Es posible aplicar kanban sin hacer Scrum/XP y pensar en Agile/Lean? Equivale a preguntarse ¿es posible tener solo el ultimo sabor del helado y además sin el cono? La respuesta es obvia, desde luego que si pero uno acaba perdiéndose los demás sabores y comodidad de tener un cono que sostenga el helado mientras uno se lo come.
¿Sería posible aplicar solo Scrum sin nada de XP? Desde luego que sí, pero en algo que no tenga que ver con software. Por ejemplo, ¿de que me serviría utilizar a cabalidad Scrum si mi proyecto no cuenta con un build machine que garantice la integración continua del código producido?
¿Tiene sentido aplicar los principios de XP sin pensar en Agile y Lean? Muchos equipos lo hacen, pero por mas fuertes que sean los principios XP estos no hacen hincapié en los factores humanos (me encanta llamar a esto peopleware) que son el gran capital de un proyecto. Lean es especialmente útil aquí, después de todo Lean es aquella cosa mágica que permitió que Toyota llegue donde llego, algo de bueno ha de tener como para dejarlo pasar :)
[1] Lean Software Development: An Agile Toolkit (Agile Software Development Series) by Mary Poppendieck and Tom Poppendieck (Paperback - May 18, 2003)
[2] http://www.agilemanifesto.org/
[3] Traduccion literal de “thinking tools”
[5] http://xprogramming.com/index.php
[8] www.scrumalliance.org
[9] http://www.infoq.com/minibooks/kanban-scrum-minibook
