La palabra du jour en la gestión de proyectos «Agile» está en dura competencia con el título de trabajo «Gerente de proyectos» por mal uso.

¿Se te ha acercado alguien y te ha dicho que no tiene ningún plan porque está ejecutando su proyecto utilizando métodos Agile? ¡Eso debería ser una bandera roja inmediata! Es común que «Agile» se use como una excusa para no escribir nada, no acordar los objetivos del proyecto, ni planificar o usar los conceptos básicos de gestión de proyectos y «hacerlo sobre la marcha», pero esto es un mal uso de la término “Agile”.

En este artículo, intentaremos aclarar algunos conceptos erróneos sobre el uso de Agile para entregar proyectos.

¿Eres Agile o sólo has dejado de documentar tu proyecto?

En 2001, un grupo de programadores se unió para crear lo que se convirtió en el Manifiesto Agile. Esta declaración (adecuadamente breve y concisa) describe los principios ágiles:

Afirma:

No exagerar, edulcorar o producir desperdicios es un elemento clave de Agile, por lo que tiene sentido que el Manifiesto Ágil sea breve y contundente, pero tal vez la brevedad haya permitido que surjan interpretaciones erróneas. La más notable es probablemente que la línea:

“Hemos llegado a valorar el software que funciona sobre la documentación completa”

Ha llegado a significar para mucha gente que «Los proyectos ágiles no tienen documentación» . Esto es incorrecto. Lo que afirma es que el software en funcionamiento (o producto/resultado) debe valorarse más que la documentación completa, no que no deba haber documentación en absoluto.

Diferentes equipos, diferentes clientes y diferentes proyectos tienen diferentes necesidades de documentación, incluso donde se usa Agile. Agile ofrece la oportunidad de alejarse de las formas tradicionales de gestión de proyectos con gran cantidad de documentos (y, a veces, dirigida por documentos) y, en cambio, buscar una forma de permitir que las interacciones, la colaboración, el producto de trabajo y la flexibilidad impulsen el progreso.

Algunos proyectos Agile se benefician de más documentación. Algunos proyectos tradicionales se benefician de menos documentación. Nadie (¡probablemente!) se beneficia de NO tener documentación.

Tal vez a lo que deberíamos aspirar es a usar el MVB (Minimum Viable Bureaucracy), o Burocracia Mínima Viable, lo que sea que eso signifique para nuestro proyecto y contexto.

¿Utilizas Agile porque es lo adecuado para tu proyecto o como una excusa para dejar de planificar?

Para algunos, puede ser una sorpresa que importe cuando usamos métodos Agile, es decir, a qué tipo de trabajo de proyecto lo aplicamos. ¡No todos los proyectos son aptos para entregarse con Agile! De hecho, uno de los temas que surgen de los Principios Agile es no generar desperdicio haciendo las cosas “porque sí”, es decir, solo debemos hacer cosas que tengan un propósito real y que agreguen verdadero valor. Por lo tanto, el uso de métodos Agile sin una buena razón es, en sí mismo, no Agile.

Entonces, ¿cuándo se deben usar los métodos ágiles? En la explicación más simple posible, los proyectos que son adecuados para los métodos ágiles son aquellos que implican un trabajo completamente nuevo en el que es imposible, o indeseable, definir todo el alcance por adelantado, o en el que es importante que obtengamos algo (como una versión anterior o una componente de la solución completa) al usuario final tan pronto como sea posible. Esto no es una excusa para salirse de la gestión de requisitos y la definición del alcance. Si el alcance se puede definir con una confianza razonable, debería ser así. Los métodos Agile son para aquellos casos en los que no se puede definir el alcance, o cuando hay tanta incertidumbre que una definición del alcance no tiene sentido.

Si tienes un alcance específico que debe entregarse «tal cual», entonces lo más apropiado es un enfoque más tradicional (con la documentación y los cronogramas relevantes).

¿Estás utilizando los métodos Agile correctamente o simplemente no estás planificando?

Hay una serie de metodologías diferentes dentro de la familia Agile. Lo que tienen en común es que se centran menos en la documentación detallada y más en la colaboración, la exploración y la adaptación. Esto, a menudo, provoca una percepción errónea de que los equipos Agile carecen de disciplina, estructura y simplemente «se lo inventan sobre la marcha».

¡Nada mas lejos de la realidad! De hecho, para utilizar métodos Agile se necesita más planificación, estructura y disciplina que en los proyectos tradicionales o “en cascada”.

Deja que me explique…

Para Agile en un contexto de proyecto, el más común es Scrum. En Scrum, un equipo dedicado trabaja en conjunto durante todo el proyecto. El proyecto se divide en fragmentos de tiempo, normalmente llamados «Sprints». Un sprint debe durar de 2 a 4 semanas. Ni mas ni menos. La razón de esto es que de 2 a 4 semanas es suficiente (advertencia: si dices que estás trabajando en sprints pero duran más de 4 semanas o no tienen límite de tiempo, no estás haciendo sprints, solo estás haciendo el trabajo en etapas).

Eso significa que cada 2-4 semanas el equipo comienza de nuevo:

• Identifican en qué requisitos trabajar
• Planean cómo cumplir con esos requisitos.
• Ellos hacen el trabajo.
• Cierran ese trabajo y evalúan cómo trabajaron y qué pueden hacer mejor.

Cada vez que el ciclo comienza de nuevo, el equipo aporta las lecciones aprendidas del ciclo anterior para garantizar que aprendan y mejoren constantemente.

Esto significa que el equipo planifica cada 2 a 4 semanas y siguen una estructura muy específica para asegurarse de que funcione. Esta es la razón por la cual un equipo que usa Agile para entregar sus proyectos requiere aún más disciplina que uno que usa métodos tradicionales/en cascada.

¿Está dedicado el equipo?

Vaya, parece una pregunta capciosa, ¿no? Esto no es un juicio sobre la ética de trabajo de tu gente, se trata de su capacidad para concentrarse en la solución y aprender juntos a través de la experimentación, la adaptación y la colaboración.

Como se indicó anteriormente, los métodos Agile son los más adecuados para trabajar donde el alcance no está definido y eso se debe a que el verdadero valor de Agile es que brinda una forma estructurada de experimentar, aprender y adaptarse para descubrir gradualmente cuál debería ser la solución (y el alcance). A medida que el equipo trabaja a través de sus sprints y adapta sus formas de trabajar de acuerdo con las lecciones aprendidas en cada sprint, mejorarán, serán más eficientes y comprenderán mejor cuál es el verdadero valor de la solución. Esto solo se puede lograr si las mismas personas trabajan juntas durante un largo período de tiempo y, por lo tanto, se necesita un equipo dedicado y no solo una colección de profesionales que entran y salen del proyecto.

☐ ¿El alcance es verdaderamente indefinible o es probable que cambie significativamente?

☐ ¿Estás trabajando en sprints claramente definidos?

☐ ¿Estás utilizando la cantidad mínima de burocracia?

☐ ¿Planificas al inicio de cada sprint?

☐ ¿Revisas tu trabajo al final de cada sprint para asegurarte de seguir aprendiendo y mejorando?

☐ ¿Tienes un equipo dedicado?