Contexto
Las metodologías agiles son un concepto que originalmente se acuñaba al desarrollo de software, sus primeras menciones oficiales rondan 1970 cuando se empezó a criticar la forma tradicional de desarrollar un proyecto, donde las correcciones al mismo se realizaban una vez el proyectos se entregaba por completo. Viendo que esta forma de trabajar resultaba ineficiente y que las pruebas y correcciones del producto o solución se podían hacer en etapas tempranas del desarrollo, si estas eran identificadas. Con base en estos antecedentes se empezó a repensar la forma como se podían desarrollar los proyectos de la industria del software y formalmente en el 2001 se firmo un manifiesto ágil.
Herramientas
Las metodologías ágiles son un marco en el cual se clasifican una serie de herramientas que presentan un apoyo en el desarrollo del trabajo en los proyectos. De forma general, se asocia Agile con Scrum, el cual configura el marco de trabajo bajo el cual se desarrolla la metodología ágil; sin embargo, las metodologías ágiles cuentan con una gran variedad de metodologías menores o sub-herramientas que permiten entender y ejecutar el desarrollo del ejercicio ágil de forma comprensible y clasificar el desarrollo de los proyectos de acuerdo a su complejidad. Dentro de este conjunto de herramientas vale la pena resaltar Kanban, XP (Extreme Programing), desarrollo Lean, Cristal Clear y por supuesto Scrum; a continuación se procede a realizar la explicación de cada una de estas herramientas y el papel que ocupan al interior de lo que entendemos por Agile.
Scrum
Scrum se describe como el marco de trabajo Agile por excelencia. Dentro de Scrum de identifican roles, tareas y las etapas principales para el desarrollo de un proyecto. Es común en un grupo de trabajo con metodología Scrum cuente con un Product Owner, un Scrum Master y un Scrum Team de no más 8 personas. Estre grupo de trabajo descrito busca constantemente las victorias tempranas y documentar las oportunidades de mejora identificadas en cada proceso a través de cada iteración (sprint) o entrega de versión del Producto Mínimo Viable (esto con el fin de generar valor a futuro en proyectos de índole similar o si es necesario replantear el proyecto desde desde una etapa previa o el principio).
Al interior de grupo de trabajo Scrum existen 2 posiciones verticales y una horizontal.
La posición principal es ocupada por el Product Owner (Dueño del producto o cliente directo en algunas ocaciones) quien se encarga de establecer las necesidades que deben ser satisfechas con el producto a desarrollar, este actor debe entregar los requerimientos mínimos que deben ser cubierto y por ello debe estar probando constantemente el producto con el fin de verificar su satisfacción y cumplimiento, es común que se evalúe el producto al final de cada iteración del producto (o entrega de versión del Producto Mínimo Viable). El Product Owner el único agente dentro del equipo que puede modificar las características que debe cumplir el producto y el documento que respalda el plan a cumplir (Product Backlog).
La segunda posición al interior de grupo de trabajo Scrum es ocupada por el Scrum Master, esta persona es responsable ante el Product Owner de la ejecución del plan (Product Backlog), de transferir la información de manera pertinente al Scrum Team con el fin de establecer las entregas que serán autosugestionadas por su integrantes y de facilitar y romper con las dificultades que se presenten al interior del Scrum Team con factores externos a las tareas de autosugestionadas. El Scrum Master para realizar el seguimiento al Product Backlog realiza un Daily Scrum (rutina diaria al empezar la jornada) donde los miembros del ScrumTeam brevemente comentan sus avances del día anterior, la tarea del día, su ruta de acción para completar dicha tarea y los potenciales obstáculos que pueden enfrentar en las tareas de días futuros (para que el Scrum Master les allane el paso en el futuro y se puedan completar las tareas con eficiencia y eficacia).
Por otro lado, el Scrum Team esta integrado por personas técnicas su ejercicio que buscan completar tareas puntales al interior del proyecto y que autogestionan su acción con el objetivo brindarle velocidad al desarrollo del Producto Mínimo Viable. Los miembros del Scrum Team deben contar con una bitácora de proyecto donde apuntan los retos que enfrentan con la tarea que ejecutan en el momento, las soluciones a esos retos que encuentran y los pasos a seguir en el desarrollo de su tarea, esto con el fin de dinamizar el tarea y facilitar el Daily Scrum.
El equipo de trabajo Scrum desarrolla Iteraciones o Sprints, estos idealmente no deben superar las 6 semanas. En cada Sprint se entrega un Producto Mínimo Viable con el cual el Product Owner prueba y valida las hipótesis del producto y/o el modelo de negocio.
Si bien Scrum entrega una buena visual de lo que se busca con Agile como metodología, es necesario entender las demás herramientas que brindan soporte al trabajo ágil y que permiten mejorar la gestión al interior de las organizaciones.
XP (Extreme Programing)
Si bien XP o Extreme Programing hace referencia al mundo del Software y la computación, la metodología en si misma configura los pasos por las cuales se pasa en Scrum.
Para el XP las visones del cliente frente al producto y la velocidad con las que estas se ejecuten son el foco de atención. Las visiones del cliente se deben interpretar para ser transmitidas al equipo en forma de plan. Una vez se tiene el plan de trabajo, se deben validar las aproximaciones del equipo (los entregables) con los objetivos establecidos, si se cumple con los objetivos establecidos, se incorporan al proyecto para la construcción del Producto Mínimo Viable que se presentará en la iteración o Sprint.
En la medida que se van acumulando avances alineados con las ideas del cliente y mejorando el PMV se va generando un producto preliminar que es probado por el cliente bajo distintos escenarios, si el producto cumple con as exigencias y no requiere más mejoras es entregado, si el proyecto presenta una relativa complejidad, este puede generar entregas de producto parciales finales que vayan saliendo al mercado o la implementación del cliente interno.
Cuando el producto debe ser modificado por que no cumple con los objetivos o porque la visión del cliente a cambiado, se debe replantear la planeación del mismo, esto con el fin de mantener alineados a todos los integrantes del Scrum Team y tener una adecuada visual en los avances de los objetivos presentados por el cliente.
Kanban
Kanban viene del japonés Kan “Signo” y Ban “Tarjeta visual”. El tablero Kanban fue Desarrollado por Toyota para su Sistema de Producción con el objetivo de mantener a todo el equipo informado del estado de los distintos proyectos y de minimizar el uso de los recursos (tiempo, espacio e insumos). El Kanban suele utilizarse como una herramienta de apoyo en Scrum dado que permite una comunicación permanente del estado en el cual esta la ejecución del plan de producto a todo el equipo de trabajo Scrum. Por otro lado, dado que el tablero Kanban busca a su vez reducir los tiempos y el recurso desperdiciado, se configura como una herramienta clave en las metodologías Lean. Las metodologías ágiles son un subconjunto de las metodologías Lean.
Desarrollo Lean
El desarrollo Lean (esbelto o ajustado) hace referencia al pensamiento o filosofía de las metodologías Lean donde el foco esta en el desarrollo de las actividades utilizando la cantidad mínima necesaria de recursos, espacio y tiempo para el desarrollo de las actividades de un proyecto, sin que estos atenten contra la calidad del mismo. Resulta conveniente tener esta idea como centro de las metodologías ágiles dado que estas a su vez son un subconjunto de las metodologías Lean donde se centran los esfuerzos en generar innovación en procesos específicos ligados a administración (Lean Office), la manufactura o prestación de una servicio (Lean Manufacturing), los proyectos (Lean Project) y los emprendimientos (Lean StartUp). Como veremos más adelante cuando hayamos terminado con la explicación de Agile, las Metodologías Lean son el camino a la innovación y el emprendimiento desde un enfoque de calidad y excelencia administrativa y operativa.
Crystal Clear
Crystal Clear se considera una familia de metodologías dentro de Agile donde los proyectos se clasifican según dos variables: el tamaño y la complejidad del proyecto, donde la complejidad determina el tamaño del equipo. Como se observa en la imagen de esta sección de cuadro al número de personas que sean necesarias para el proyecto, este será clasificado con un color; cada color a su vez determina la existencia de uno a más equipos equivalentes al equipo de trabajo de Scrum. En la medida que incrementa la complejidad el tiempo entre las iteraciones se puede ir ampliando; sin embargo, la visión inicial sigue lo propuesto por el manifiesto ágil: los objetivos logrados dentro del proyecto deben ser probados con el cliente con el fin de corregir de forma adecuada, eficiente y efectiva.
A pesar de que existen algunas diferencias metodológicas entre los niveles (Clear, Yellow, Organge, etc.) el principio básico sigue las dinámicas del Scrum con el XP como ruta, desarrollo Lean como filosofía y Kanban como herramienta de seguimiento en los distintos niveles jerárquicos de complejidad del proyecto.
Como se puede observar, Agile o las metodologías ágiles hacen referencia a un grupo de herramientas que en conjunto permiten facilitar la comunicación en el grupo de trabajo: generando valor agregado a partir de los aprendizajes en los distintos proyectos, velocidad a partir de la autogestión del Scrum Team y la gestión anticipada del Scrum Master, y adaptabilidad al probar constantemente con las iteraciones del Producto Mínimo Viable con el cliente y los diferentes escenarios en los cuales seria utilizado el producto, el servicio o la solución.