Hace tiempo me encontraba dando una formación sobre Scrum y un alumno me dijo que parecía que estaba demonizando a Waterfall. En el sector Agile solemos atacar a waterfall como una propuesta fallida y que debe ser solucionada por el “todo-poderoso” Agile. El debate Agile-Waterfall es esteril, son herramientas diferentes con propósitos diferentes. Waterfall, es una propuesta de trabajo muy útil según el tipo de problema que queremos resolver. Agile & Waterfall, ¿amigos o enemigos?
Bienvenidos a Waterfall
Imagina que tenemos que construir cuatro aviones Airbus 320 similares. Para cada uno de ellos disponemos de un mes con una cantidad económica similar de 100.000$. Nos encontramos en el mes 3 del proyecto y esta es la situación:
- El primer avión ya se encuentra terminado y en fecha, aunque con sobrecoste.
- El segundo avión se encuentra terminado antes de tiempo.
- El tercer avión ha comenzado pero solo lleva un 70% y gastando 80.000$.
- El cuarto avión ha comenzado antes de tiempo y se encuentra al 50%.
Este proyecto se puede medir con diferentes fórmulas que nos indican el estado del proyecto. Es lo que conocemos como la Técnica de Valor Ganado que propone el Project Management Institute (PMI). Esta técnica cruza el tiempo, el coste y el alcance para que podamos entender el estado del proyecto y su desviación.
Estas fórmulas funcionan porque comparan el plan original con la situación actual. De esta manera podemos gestionar las expectativas con clientes y tomar decisiones para reconducir el proyecto hacia el plan original.
¿Qué pasa cuando aplicamos estas fórmulas en un Proyecto Agile?
Cuando el alcance varía, cambia todo
Una vez me dijo un compañero que hacer proyectos era tan sencillo como caminar sobre el agua. La clave de los proyectos y del agua es que tanto los requisitos como el agua estén congelados.
Si congelamos el alcance, podemos aumentar nuestras opciones de acertar ante una estimación. El problema radica en que, cuando estamos resolviendo problemas complejos, el alcance varía porque la solución no es predecible. Que las tareas que tenemos que resolver varían es positivo, significa que nos adaptamos en cada situación a lo que nos encontramos.
Imagina que partimos con el siguiente backlog con diez tareas que queremos desarrollar en los próximos 10 meses. Al igual que los aviones le asignamos un coste a cada uno de ellos para poder planificar el futuro de nuestro producto.
Tras dos sprints nos encontramos con la siguiente situación:
¿Cuál es el estado actual del proyecto? ¿Vamos bien o vamos mal? ¿Cuál es la comparación con respecto al plan original? ¿Cómo podemos corregir la desviación?
En el momento en el que aceptamos nuevos items, cancelamos los que previmos y modificamos los actuales, el enfoque tradicional de comparar el plan original con la situación actual carece de sentido. Y esto no es malo porque realmente estamos adaptando lo que hacemos a la necesidad real que estamos descubriendo de nuestro cliente. ¡El éxito de un equipo no es acertar con el plan!
Esta es la diferencia entre el enfoque predictivo y el adaptativo.
Cómo elegir el enfoque
Cuando nos enfrentamos a un problema complejo debemos aplicar alguna técnica Agile (Scrum, método Kanban, XP en el caso de software…). Un problema complejo se detecta porque es imposible planificar, porque el alcance va a sufrir cambios contínuamente.
En el momento que nos enfrentamos a un problema donde ponemos planificar a nivel de tarea y persona, entonces un enfoque predictivo puede sernos más útil que Agile. El motivo es que, si se puede planificar significa que el debate de reordenación que se produce con el Product Backlog carece de sentido.
Otro ejemplo puede ser aquellos procesos que son muy lineales y secuenciales. Cuando existe una secuencia y además podemos definirlo de manera nítida, es mejor un enfoque predictivo.
Sin embargo, si estamos probando una nueva tecnología con la que tenemos dudas de su fiabilidad, es mejor aplicar un enfoque Scrum/Agile porque, en cada iteración, utilizaremos lo aprendido para avanzar en el uso de esta tecnología.
Por ejemplo, si queremos diseñar (por primera vez) la Energía Nuclear, puede que usemos un enfoque Agile de prueba-error. Ahora bien, cuando ya dominamos la tecnología, planificamos hasta el mínimo detalle cada vez que construimos una nueva central nuclear.
Y tú, ¿crees que Agile y Waterfall son amigos?
