Los modelos híbridos más avanzados van más allá de una simple secuencia de Cascada + Ágil. Introducen el concepto de "fases adaptativas", donde el equipo no solo sigue un plan, sino que elige dinámicamente el mejor enfoque para cada tipo de trabajo. Esto permite una gestión fluida y contextual del ciclo de vida del producto, desde la concepción de una idea hasta su mantenimiento a largo plazo.
8.1. Alternar planificación, ejecución y soporte
En lugar de ver el desarrollo como un proceso lineal, las fases adaptativas lo conciben como un ciclo continuo donde coexisten diferentes modos de trabajo. Un equipo puede estar simultáneamente en varias "fases" dependiendo de las tareas que tenga entre manos.
Las tres fases principales que se alternan son:
- Fase de Planificación (Estratégica): Se corresponde con el enfoque tradicional. Aquí se definen las grandes iniciativas, se investigan nuevas ideas, se crea el roadmap del producto a largo plazo y se establecen los presupuestos. Esta fase no ocurre solo al principio, sino que se revisita periódicamente (por ejemplo, cada trimestre) para ajustar la estrategia.
- Fase de Ejecución (Desarrollo de Producto): Se centra en la construcción de nuevas funcionalidades. El modo de trabajo predominante aquí es Scrum, con su estructura de Sprints, planificación de iteraciones y entregas incrementales. El objetivo es desarrollar y validar rápidamente las ideas definidas en la fase de planificación.
- Fase de Soporte (Flujo Continuo): Gestiona el trabajo reactivo e impredecible. Aquí se utiliza Kanban para manejar bugs, dar soporte a usuarios, y realizar pequeñas mejoras. El objetivo es mantener el producto estable y responder rápidamente a las necesidades del día a día sin interrumpir la fase de ejecución.
Un equipo maduro aprende a "cambiar de marcha" y a dedicar una parte de su capacidad a cada una de estas fases según las prioridades del negocio.
8.2. Transiciones entre fases según el tipo de tarea
La clave de las fases adaptativas es tener reglas claras para mover el trabajo de una fase a otra. Las transiciones no son rígidas, sino que dependen de la naturaleza de la tarea.
Deliberación (Planificación) → Ejecución
Una nueva iniciativa grande (p. ej., "crear un nuevo módulo de reportes") no entra directamente en un Sprint. Primero pasa por una fase de deliberación donde:
- El Product Owner y los stakeholders definen los objetivos de alto nivel.
- Se realiza un análisis de viabilidad técnica y de mercado.
- Se crea un conjunto inicial de épicas o historias de usuario.
Solo cuando la iniciativa está lo suficientemente madura y priorizada, sus componentes se mueven al Product Backlog para ser considerados en futuras planificaciones de Sprint.
Ejecución ↔ Soporte
La interacción entre la ejecución (Scrum) y el soporte (Kanban) es constante:
- Bug encontrado durante el Sprint: Si un desarrollador encuentra un bug relacionado con la funcionalidad que está construyendo, lo arregla de inmediato como parte del trabajo del Sprint.
- Bug reportado por un usuario: Un bug de producción se registra como una tarjeta en el tablero Kanban de soporte. El equipo (o una parte de él) lo analiza y prioriza. Si es crítico, puede justificar la creación de un "carril de alta prioridad" (expedite lane) en el tablero para que se solucione de inmediato, incluso si eso implica pausar una tarea del Sprint.
- Mejora pequeña: Una solicitud de mejora menor (p. ej., "cambiar el color de un botón") se añade al backlog del tablero Kanban y se aborda cuando hay capacidad disponible, sin necesidad de esperar a un nuevo Sprint.
8.3. Ejemplo: sprint de desarrollo + tablero Kanban de bugs
Este es el ejemplo más común y práctico de fases adaptativas en acción, y es la esencia del modelo Scrumban.
Imaginemos un equipo que trabaja en Sprints de dos semanas para desarrollar nuevas funcionalidades de un producto ya existente. Así es como organizan su trabajo:
- Planificación del Sprint: Al inicio del Sprint, el equipo selecciona un conjunto de historias de usuario del Product Backlog que se compromete a completar. Estas historias representan el trabajo de ejecución.
- Tablero de Sprint (Scrum): El progreso de estas historias se visualiza en un tablero Scrum, que puede tener columnas como "Por Hacer en Sprint", "En Progreso", "En Pruebas" y "Hecho". El objetivo es mover todas las tarjetas a "Hecho" antes de que termine el Sprint.
- Tablero de Soporte (Kanban): Paralelamente, el equipo tiene un segundo tablero, o un área designada en el mismo tablero, para el trabajo de soporte. Este tablero tiene sus propias columnas (p. ej., "Nuevo Bug", "Analizando", "Solucionando", "Desplegado") y, lo más importante, tiene límites de WIP. Por ejemplo, el equipo puede decidir que no puede haber más de 2 bugs "En Progreso" al mismo tiempo.
- Asignación de capacidad: El equipo decide dedicar una parte de su capacidad a cada fase. Por ejemplo, pueden acordar que el 80% de su tiempo se dedicará a las historias del Sprint y el 20% a atender el tablero Kanban. Esto evita que el trabajo de soporte canibalice por completo el desarrollo de nuevas funcionalidades.
- Flujo de trabajo diario: Durante el Daily Scrum, el equipo revisa ambos tableros. Primero se aseguran de que no haya impedimentos en el tablero Kanban (los bugs suelen tener mayor prioridad). Luego, discuten el progreso hacia el objetivo del Sprint.
Este modelo dual permite al equipo ser predecible en la entrega de nuevas funcionalidades (gracias a Scrum) y, al mismo tiempo, ser altamente reactivo a los problemas y necesidades imprevistas (gracias a Kanban). Es una implementación pragmática y poderosa del concepto de fases adaptativas.