Lean y Desarrollo Ágil

Recientemente me preguntaban si las metodologías ágiles son la respuesta Lean al desarrollo de proyectos. La idea es interesante; yo estoy convencido de que podemos utilizar herramientas de calidad en muchas partes, tanto de la administración como ingeniería del desarrollo de software, así que exploremos más esta idea.

La metodología Lean fue desarrollada por Toyota en los noventas, como una práctica de producción que considera como desperdicio el uso de recursos en actividades que no generen valor para el cliente, definiendo valor como todo aquello que el cliente esté dispuesto a pagar. Lean conlleva una serie de herramientas diseñadas para eliminar este desperdicio, entre ellas el mapeo de valor, las cinco S, Kanban (o proceso de jalar en lugar de empujar) y Poka Yoka (desarrollo a prueba de errores).

El modelo ágil de desarrollo de software se formalizó en el 2001 con el Manifiesto Ágil, aunque tiene raíces desde mucho antes. Este modelo busca la agilidad a través de valorar la interacción entre las personas, la colaboración y la flexibilidad al cambio. El manifiesto define doce principios enfocados a: satisfacción del cliente a través de desarrollo rápido; flexibilidad al cambio; entrega continua de software; entrega es la base del avance; flujo continuo a través de un paso constante; cooperación continua entre participantes; comunicación frente a frente;  confianza en los participantes; búsqueda de excelencia; simplicidad; auto-organización;  adaptación a circunstancias de cambio.

A primera vista, el manifiesto promueve todos los principios de Lean: establece un modelo de Kanban, donde se tiene un paso continuo; una estructura en donde el cliente rige cada iteración, que puede ajustarse continuamente; estipula también una reducción de documentación y la cercanía de los participantes para poder asegurar una mejor comunicación.

Lean se creó como una herramienta de manufactura, por lo que requiere ser adaptada para ser utilizada en servicios. La principal adaptación que sufre es la modificación de los elementos que se consideran desperdicio. A continuación explico como Ágil ataca los problemas de desperdicio.

Desconocimiento de expectativas del cliente. Ágil ataca este problema al generar entregables continuos, y al tomar como medida de avance el software funcionando. Esto establece en forma indirecta que la participación del cliente siempre está relacionada con avanzar.

Energía y duplicidad de trabajo. Aunque Ágil fomenta el generar trabajo a través de pares, esto no va contra este principio porque la idea detrás de esto es que cada individuo busque defectos desde un punto de vista diferente, minimizando así el re-trabajo.

Errores de comunicación. Ágil fomenta la comunicación verbal como una forma eficiente de obtener claridad.

Inventario incorrecto. A diferencia de metodologías que miden el avance de un proyecto en base a actividades realizadas, en Ágil el avance se mide en términos de “software funcionando”.

Errores en el servicio. Lean fomenta un retroalimentación continua y la detección de errores lo antes posible a través de revisión y retroalimentación continua.

Potencial humano no utilizado. Lean fomenta la participación de todos en todas las etapas de desarrollo y la distribución de roles en forma grupal.

En base a esta rápida comparación, definitivamente Ágil se puede considerar como una forma Lean para desarrollar software y que por lo tanto acarrea sus beneficios.

Tips para la adopción

Un inconveniente de Ágil es que al ser tan flexible, las implementaciones pueden variar considerablemente, permitiendo mucho uso inapropiado del modelo. Por ejemplo, recordemos que Lean considera valor agregado todo aquello que está dispuesto a pagar el cliente, por lo que si el cliente paga por tener documentación de su sistema, eso es parte de los entregables.

Otra situación común es que los equipos decidan eliminar actividades como reuniones periódicas de retroalimentación o programación en pares, las cuales tienen una razón de ser; eliminarlas sin cuestionar cómo sustituimos las prácticas equivale a remover acciones de valor agregado del modelo.

Por otro lado, no debemos ser tan rígidos, ya que seguramente nos encontraremos con situaciones especiales donde ya sea por tamaño de proyecto o dispersión geográfica, es posible sea necesario aplicar prácticas de metodologías no tan ágiles.

En resumen, definitivamente las metodologías ágiles son una excelente solución al desarrollo de software pero como todo en esta vida tenemos que cuestionar la razón de las actividades que vamos a llevar a cabo, y más importante, cuestionar la razón de las actividades que decidimos dejar de implementar