Reflexión sobre el papel que juegan las planificaciones en proyectos ágiles.

1. Javier Martín de Agar Tirado
En Agile no se hacen planes!

2. “En agile no se hacen planes”
Muchas personas creen que en proyectos Ágiles
no es necesario planificar. Se escapa del uso del
Diagrama de Gantt en este tipo de proyectos
pero no debemos olvidar la siguiente cita:
“Los planes son inútiles, pero planificar lo es todo”
D. Eisenhower
¿Cómo relacionamos los planes en un modelo
ágil?

3. ¿Por qué es bueno planificar?
¿Hacia dónde vamos?
• Un plan ayuda a conocer el
futuro del proyecto.
• Conocer los siguientes
pasos nos ayuda a no dar
“bandazos” y transmitir
sensación de
desorientación.
• Ir superando etapas hace
que el equipo se reconforte
¿Cómo trabajamos con
los demás?
• Tener un plan ayuda a
coordinarnos con agentes
externos al proyecto.
• Sabiendo en qué momentos
vamos a necesitar a los
terceros disminuye los
retrasos que afecten a
nuestro proyecto.
¿Qué queremos
conseguir?
• Un plan nos despeja la duda
de los objetivos del proyecto
• Si el plan es público, el
equipo entenderá los
objetivos y eso ayudará a
comprender al cliente. (esto
fomenta la responsabilidad)

4. ¿Por qué no nos gustan los planes?
 El problema de la planificación es la atadura a la
misma. En un modelo tradicional se genera un
plan muy cerrado que al final se convierte en el
eje del proyecto.
 Cuando un plan es el eje, hace que todo se
centre en el cumplimiento del plan con lo que
muchas veces las personas dejan de ser
importantes.
 El equipo no se centra en generar valor para un
cliente, si no en cumplir estrictamente el plan.
 Además, cuando el cliente quiere cambios (que
siempre aparecen) esto genera tensión al tener
que cambiar el plan.

5. ¿Qué papel juegan los planes en
Agile?
Es bueno partir de un plan pero sabiendo que cambiará
• Podemos tener un plan, pero siendo consciente de que cambiará y que es solo una
guía, un mapra para el equipo pero no el objetivo del equipo.
Controlar las expectativas
• Cuanto más intentemos predecir el futuro más aumentaremos el error. Un plan que
pase de 6 meses tiene un % de error muy elevado por lo que hay que tener cuidado
con las promesas que le hacemos al cliente.
• Cuando detectemos un cambio importante en el plan, es bueno comunicarlo al PO.
La transparencia genera confianza y eso ayuda al proyecto.
No invertir demasiado tiempo
• Sabemos que los planes fallan por mucho tiempo que intentemos invertir. Es mejor
dirigir ese tiempo a otras tareas e invertir lo mínimo para saber hacia donde vamos.
Un plan de versiones (release plan) es suficiente
• Lo importante es conocer los próximos Sprints y las siguientes versiones que
liberaremos. Más detalle nos generará un desgaste para saber que nos
equivocamos.

6. Conclusiones
 Tener un plan ayuda a guiar al equipo.
 Los planes fallan pero es importante saber hacia
donde vamos
 Ya que fallarán no debemos invertir más tiempo
del necesario.
 Lo importante son las personas, los planes son
medios pero no fines.
 Un plan release puede ser suficiente en un
proyecto Scrum y nos servirá para coordinarnos
con terceros.
 No debemos hacer promesas (expectativas) a
muy largo plazo, es muy probable que