Uno de los modelos que se está poniendo de moda en los últimos tiempos es el modelo híbrido resultante de la unión entre Agile y Waterfall. El modelo híbrido es una solución que está funcionando en muchos clientes como método menos disruptivo de lo que supone una implantación Agile.
Siempre que se unen dos métodos de trabajo, hablamos de coger lo mejor de cada uno de ellos. De hecho, muchas personas defienden la idea de que no hay que cerrarse a un método concreto, sino coger de cada uno aquello que mejor funciona. ¿Por qué no unir un modelo que ha funcionado tantos años como Waterfall con la moda Agile para arrasar?
Vamos a analizar la dificultad de mezclar este tipo de métodos ya que parten desde puntos diferentes.
El chico que era de los dos equipos
Para quien no lo sepa, en mi ciudad, Sevilla, existen dos equipos de fútbol con mucha historia y rivalidad: el Betis (del cual soy seguidor) y el Sevilla. Hace unos años, pude ver una película (cuyo nombre no recuerdo), inspirada en la Sevilla de los años 70. La película nos mostraba las dificultades de un chico para adaptarse a Sevilla, ya que provenía de otra ciudad lejana. En una escena, podíamos mos ver su primer día de clase en la que el profesor le pregunta que si es del Betis o del Sevilla. En ese momento, toda la clase se le queda mirando en silencio y el niño, asustado y sin saber que decir, responde “de los dos”, a lo que le sigue una carcajada general de la clase.
Cualquiera que sea de Sevilla sabe que hay una rivalidad muy fuerte y que es imposible ser de los dos equipos de fútbol a la vez.
¿Significa esto que debemos elegir entre Agile o Waterfall como si fueran equipos de fútbol? Para nada, ambos planteamientos tienen sus pros y sus contras, y entornos donde tienen sentido cada uno de ellos. Plantearnos hacer una Central Nuclear con Agile sería una locura: “en este Sprint ponemos el núcleo de plutonio y veamos qué ocurre, lo importante es fallar rápido” ¡Sería una locura!
El modelo híbrido Agile y Waterfall
Hay muchas maneras de hacer el modelo híbrido ya que depende de cómo unamos los diferentes elementos. En la mayoría de ellos, se hace un planteamiento Waterfall alto nivel en el que nos fijamos una fecha, un alcance y unos costes; después, el día a día se hace con Agile. De esta manera, eliminamos la barrera que produce en muchas empresas el no dar una fecha antes de empezar, y podemos aprovechar la inspección y la adaptación en iteraciones que propone Agile de cara a “controlar” que se alcanza dicha fecha o para incorporar cambios durante el proceso.
De esta manera, nuestro proyecto waterfall gana transparencia a medida que lo vamos desarrollando, gracias a los diferentes eventos que podemos usar en Agile. Por ejemplo, con Scrum disponemos de la Daily Scrum para inspeccionar y adaptar cada día, o la Sprint Review para revisar el estado del proyecto. Sin embargo, Scrum y Agile no se pensaron para cumplir la fecha, no tienen ese propósito, a pesar de que pueda ayudar a gestionar riesgos para tratar de alcanzarlo. Llegar a una fecha no es sinónimo de éxito si el producto que creamos no cumple su función o no es rentable.
Predictivo o Adaptativo
El gran problema de unir Waterfall con Agile no está relacionado con sus prácticas, un diagrama de gantt puede ser Agile y una historia de usuario puede ser tradicional. Todo depende del planteamiento o del mindset que tengamos por detrás. En Waterfall, tratamos de invertir mucho tiempo al principio; así podemos entender todo el problema antes de arrancar, con ello creamos un plan y, a partir de ahí, toda la gestión se enfoca en el cumplimiento del plan. Este modelo es conocido como predictivo, ya que tratamos de averiguar todo lo que va a pasar antes de empezar.
Agile funciona de manera distinta, ya que su gran potencia es la capacidad de adaptación. Ponemos el foco en el usuario, en el mercado y en los objetivos de valor que nos marquemos. A partir de ahí, en equipo, vamos trabajando, haciendo paradas para preguntarnos si vamos por el buen camino que nos marcamos. Además, fijamos métricas que nos permitan tomar decisiones sin perder tiempo en estimar ya que es desperdicio. El objetivo es ser capaces de crear productos que realmente sean útiles.
Ser prescriptivo tiene el problema de la cantidad de esfuerzo que se genera para crear el plan, lo que genera dolor cuando queremos cambiarlo. En Agile, preferimos arrancar cuanto antes y aprender; el modelo empírico fomenta el aprendizaje a través de la experiencia y el tomar decisiones a medida que aprendemos, no tomarlas todas al principio.
Resolviendo la vacuna del COVIT con waterfall
Imaginad que tuviéramos 10 millones de € y que queremos invertir para conseguir una vacuna para la COVID-19. Podríamos contratar un equipo de científicos y decirle que tienen tres meses para conseguirlo, pero sabemos que esto no funciona así. El dinero permite constituir un equipo de trabajo que tendrá un tiempo máximo para investigar (hasta que se acabe el dinero). Este equipo sabe hacer vacunas y tienen muy claro el objetivo, pero no te puede garantizar que lo va a conseguir.
Además, la calidad es clave, no se trata de tener una vacuna sino de que sea fiable y de que cubra un porcentaje de población muy elevado. Con todas estas premisas, lo interesante de un equipo es que vaya haciendo experimentos y probando. Y cuidado, podemos llegar a la conclusión de que no se puede crear una vacuna o de que el coste va a ser de 200 millones.
Lo importante de un equipo de científicos es su capacidad de adaptación, no se gastan todo el dinero en un solo experimento, prefieren probar muchas hipótesis para tratar de aprender y acabar acertando. Agile se basa en el empirismo como método de trabajo, diametralmente diferente al modelo predictivo.
Entornos complejos
El motivo por el que Waterfall y Agile no se combinan es porque cada uno de ellos está pensado para entornos diferentes. En entornos, complicados o simples, donde controlamos la cantidad de trabajo que hay que hacer, tiene sentido gestionar un plan para saber lo que nos va a costar. Cuando trabajamos en entornos complejos donde hay mucha incertidumbre, es mejor ser adaptativos ante la adversidad (porque no la podemos predecir) que tratar de imaginar lo que va a ocurrir.
Cuando hay demasiadas variables en juego, acabamos creando un plan totalmente ficticio que nadie se lo cree y, por eso, Waterfall no termina de funcionar en entornos complejos. No podemos crear un modelo híbrido entre Waterfall y Agile, ya que no se puede mezclar un modelo Predictivo con otro Adaptativo.
Gastar dinero o ganar dinero
Cuando aplicamos Waterfall o Agile a nivel de portafolio o de compañía, tenemos que tomar una decisión muy importante: gastar o invertir el dinero. El modelo Waterfall trata de controlar los costes, no queremos que todas las iniciativas que vamos a lanzar no ocurran y se disparen de precio. Por este motivo, el trabajo de los Jefes de Proyecto es controlar que no nos salgamos del plan y del coste establecido.
En Agile, aparece el concepto de Business Agility: la capacidad de una organización de adaptar su negocio en función de cómo fluye el mercado. Para las empresas que la interiorizan, Business Agility es su capacidad de generar beneficios y ganar dinero por encima de controlar los costes. Evidentemente, medimos lo que nos cuesta un equipo, pero ponemos más foco en el impacto y en el retorno de inversión de cada uno de ellos. De esta manera, decidimos cuáles potenciar, cuáles continuar y cuáles parar.
Modelo híbrido
Desde mi punto de vista, el modelo híbrido aparece en empresas que no han interiorizado lo que significa Agile y, por eso, creen que es posible unirlo con Waterfall. Agile no es un método desarrollo es una manera de generar valor mediante la adaptación. Para hacer Agile, la clave es medir el valor de los productos y, por tanto, los equipos ágiles deben ser capaces de responder a la pregunta: ¿cómo mido el valor de mi equipo?
Sin métricas de agilidad no podremos saber si estamos siendo realmente efectivos. Y tú, ¿Agile o Waterfall?
Hola Javi. Qué opinas de FDD (Feature-driven development)?
Buenas! ¿Con respecto a qué? 😅
FDD está considerado un método Agile y tiene una parte predictiva (las primeras fases de diseño del modelo general, creación de una lista de funcionalidades y planificación) y luego una parte adaptativa, iterativa e incremental (diseño y construcción de cada funcionalidad). No se parece mucho a ese enfoque híbrido que describes en el artículo?
Pues la verdad que no tengo mucha experiencia con FDD, algo más con BDD y TDD. FDD se considera ágil entiendo por su construcción basada en iterativo e incremental. Cierto es, que le da más importancia al previo, para mí eso lo sitúa en peligroso, en muchas organizaciones eso se demora meses y volvemos al planteamiento predictivo excesivo.
Otra cosa que no termina de convencerme, FDD se crea como técnica de desarrollo software, genial. Sin embargo, lo que más me gusta de Scrum es que no es para desarrollar software, sino para generar valor (haciendo software). Este matiz para mí es la clave y la gracia, el contrastar nuestro trabajo contra los resultados reales de negocio que produce. Sino, seguiremos sin una colaboración estrecha negocio-it.
¿Cómo lo ves tú?
Creo que al menos conviene saber que ésto existe, que esa búsqueda de modelos híbridos entre Agile y Waterfall no es nada nuevo y que algunas aproximaciones como FDD y los Crystal Methods pueden aportanos algunas ideas interesantes.
Actualmente hay muchas prácticas y conceptos ampliamente usados dentro de Scrum que vienen de otros modelos. Las historias de usuario, los Spikes, TDD… que vienen de XP. Algunas técnicas de refinamiento (como los tres amigos) que vienen de BDD. Conceptos de integración contínua de DevOps…
Sinceramente, muchos proyectos que dicen ser Scrum o intentan serlo se me parecen mucho más a FDD que a Scrum. Y no creo que eso sea malo de por sí. Funciona en su ámbito. Pero se llama de otra manera. Y llamarlo por su nombre, reconocerlo, aceptarlo y estudiarlo, puede reducir mucha frustración y puede limar muchas asperezas.
FDD sí reconoce títulos (arquitecto, backend, frontend, tester…). Hay un jefe de proyecto. Los equipos pueden ser todo lo grandes que se necesite. Tiene unas primeras fases secuenciales, donde se crea un diseño/esqueleto/arquitectura antes de desarrollar y un plan general donde sí se piensa en un alcance y fecha. Luego las últimas fases se repiten en ciclos cortos de 2 ó 3 semanas. Se identifican funcionalidades, se trabaja sobre ellas y se van cumpliendo hitos. No es Scrum. No es Waterfall.
La gracia es que llegue un momento donde ese proyecto pase a ser claramente un producto. Cuando pase el tiempo, con suerte, ya por fin no habrá fechas ni alcance definidos, los requisitos irán apareciendo según se necesiten y empezaremos a poder hacer el Scrum que nos gustaría.
También puede ayudarnos a detectar ciertas situaciones “curiosas” que deberían ponernos en alerta. He tenido casos reales donde he sugerido “oye, eso que pides no es Scrum, pero no pasa nada, existe cosas como FDD que se aproximan más a lo que quieres y podríamos valorar algo de ese estilo”, y he recibido respuestas del tipo “pero eso no lo usa nadie, todo el mundo usa Scrum, yo quiero Scrum. O si no Kanban.”
Prince2 agile, me parece una buena manera de combinar waterfall y agile.
Como bien has comentado, se aplica Prince2 y se hace un plan de proyecto, pero con «liena gruesa», es decir, no deja de ser una estimación y todo el mundo debe ser consciente.
A la hora de entregar y construir productos, sí que se puede aplicar Agile (donde se pueda, claro, Prince2 agile no es solo para desarrollo software).
Y esa entrega de productos a corto plazo, va modificando la gran planificación, la cual, va evolucionando con el tiempo.
Yo lo veo práctico y viable.