Agility at work: 7 diferencias entre una planificación tradicional y una ágil

Una de las cuestiones que suele subvalorarse o no entenderse con facilidad al implantar prácticas ágiles es el cambio de chip que conlleva el agilismo en cuanto a la planificación. Normalmente existe una cierta resignación respecto de que el plan, aunque necesario y útil para arrancar el proyecto, luego, pierde protagonismo en el día a día del proyecto. Durante la ejecución del proyecto el plan suele ser visto más como un apoyo para el control del proyecto que para gestionar la posible re-planificación y reorientación del del proyecto. En ámbitos de proyecto con una alta dinámica en cuanto a cambios, la planificación y el plan, para ser útiles, deben acoplarse al día a día del proyecto.

Antes de entrar en materia respecto de las diferencias entre planificación ágil y tradicional hay que enfatizar que al implantar agilismo en un equipo-proyecto/producto/servicio lo primero que debería evaluarse es si efectivamente en dicho contexto específico tiene sentido planificar :-). Cuando la demanda de trabajo proveniente desde la parte cliente NO se agrupa para acordar su entrega en un plazo, es decir, si lo que se espera es que el trabajo solicitado por el cliente se entregue continuamente, en este caso, lo esencial es priorizar continuamente el trabajo pendiente, abordar el trabajo más prioritario y entregarlo en cuanto se termine (intentando cumplir con ciertos niveles de acuerdo de servicio que puedan haberse acordado). Si la dinámica de cambios del proyecto es muy alta, el esfuerzo invertido en planificación puede ser significativo y probablemente no llegue a rentabilizarse. En estos casos lo pragmático sería centrarse en generar ese buen flujo de trabajo terminado que nos lleve a avanzar hasta la finalización del proyecto. En esta situación la estimación del trabajo y su contraste con la capacidad del equipo podría ser opcional o incluso no hacerse. Lecturas recomendadas: Patrones para planificación y seguimiento ágil y ¿Kanban o Scrum? that is not the question.

Bueno, hecho ya este paréntesis previo, en el resto de este post supondré que en el contexto de trabajo al cual nos enfrentamos la planificación tiene sentido.

La imagen anterior ilustra a grandes rasgos las diferencias entre un plan ágil y uno tradicional. A continuación se detalla en una tabla algunos aspectos de la planificación que considero más destacables, pero no pretende cubrir todos los aspectos que podrían contrastarse. Así también, cada aspecto es planteado en términos de lo que usualmente se hace (o se supone que se debería hacer) cuando se aplica cada enfoque. Sin embargo, en un contexto específico para algunos aspectos de la planificación lo más apropiado podría sea una mezcla tradicional-ágil, o que algunos aspectos convenga abordarlos de una forma tradicional y otros de una forma ágil.

Aspecto de planificación	Enfoque Tradicional	Enfoque Ágil
Elementos del plan	Fases o tareas que normalmente se refieren a actividades técnicas que realizará el equipo, no a elementos solicitados explícitamente por el cliente. Se suele incluir tareas asociadas al inicio y cierre del proyecto.	Sprints que contienen ítems de trabajo. Los ítems de trabajo son parte del resultado final del proyecto, es el cliente quien los establece. Normalmente no se incluye el trabajo asociado al inicio y cierre del proyecto, el trabajo en un sprint se centra en lo que sería la ejecución del proyecto.
Resultado asociado a hitos	El resultado de la fase o tareas, no es necesariamente una parte del resultado final del proyecto, podría ser un resultado intermedio que no forme parte de lo que el cliente va a explotar como resultado del proyecto.	Se obtiene un incremento hacia el resultado final del proyecto. Dicho incremento “potencialmente” podría ser utilizado por el cliente, o al menos validado (antes de finalizar el proyecto).
Frecuencia de hitos	No regular, y pueden estar bastante distanciados.	Regular, se intenta que los sprints tengan la misma duración. Un sprint no debería durar más de un mes.
Ordenamiento del trabajo	Basado en el ordenamiento de las tareas técnicas y sus dependencias. No suele intervenir el cliente en el ordenamiento de tareas.	Basado en priorización de ítems de trabajo. La priorización la decide el cliente considerando principalmente el valor del ítem en el contexto del resultado final del proyecto. Los ítems más prioritarios se realizarán en los primeros sprints.
Gestión de alcance	Se hace una distribución global de todo el trabajo indicando fechas de inicio y término de tareas. El alcance suele ser fijo y acorde a él se establecen los recursos y plazos, los cuales podrían quizás irse ajustando.	Se cuenta con un Backlog (una lista ordenada de todo el trabajo pendiente). Poco antes de iniciar un sprint se cogen los ítems más prioritarios del Backlog y se incluyen en el próximo sprint contrastando el esfuerzo asociado con la capacidad del equipo. Los cambios se reflejan en el Backlog modificando o añadiendo ítems, ante cualquier cambio se debe evaluar el punto del Backlog hasta el cual se sigue considerando como alcance del proyecto. Es decir, lo usual es fijar los recursos y plazos, y dar la oportunidad de introducir cambios, los cuales posiblemente dejen fuera parte de los ítems inicialmente incluidos en el proyecto (serían ítems de menos valor para el cliente). Lectura recomendada: Gestión de alcance en un proyecto ágil.
Asignación de responsables y estimación	Suele hacerse una pre-asignación de responsables. Tanto dicha asignación como la estimación del trabajo no suele hacerla el equipo.	Se promueve la auto-gestión del equipo. El equipo realiza las estimaciones de esfuerzo. La asignación de responsables la decide el equipo y normalmente se posterga hasta que se va a realizar el trabajo.
Cambios y re-trabajo	Cualquier cambio en el resultado esperado del proyecto así como la aparición de re-trabajo (trabajo que debe repetirse total o parcialmente por detectarse algún defecto) no es bien recibido, no solo por el impacto en el trabajo, sino por los trastornos que genera en la planificación.	El re-trabajo, no suele implicar mayores trastornos pues es tempranamente detectado. Entre la definición de un ítem y su realización no suele haber un tiempo considerable pues los ítem se detallan lo más tardíamente posible respecto de cuando efectivamente se realizarán. Como se comentó antes, los cambios se gestionan sin mayores inconvenientes en el Backlog, intercambiando nuevos ítems con ítems no realizados aún, manteniendo siempre actualizado y acordado el alcance con el cliente.