Agile de la Vida Real

¡Y todo el mundo habla de ágil pero sabes qué es? ¡Yo no veo más ninguna empresa que no trabaje con la idea de Agile!

El Agile (Ágil) es un enfoque (prefiero pensar como mentalidad) de desarrollo de software que se basa en algunos principios fundamentales establecidos en el Manifiesto Ágil.

Principios Fundamentales:

1. Individuos e interacciones por encima de procesos y herramientas
2. Software funcionando por encima de documentación abarcadora
3. Colaboración con el cliente por encima de negociación contractual
4. Responder a cambios por encima de seguir un plan

Transformación de Mentalidad

El desarrollo de software tradicional frecuentemente se parece con encargar un coche sin nunca visitar la fábrica. El cliente hace un pedido inicial detallado, el equipo de desarrollo comienza a trabajar, y tres meses después, cuando el cliente ve el producto por primera vez, surge aquella frase familiar: "No era bien eso lo que tenía en mente."

El problema no es solo técnico - es un problema de expectativas y visibilidad. El cliente piensa: "¿Cómo puede demorar tanto tiempo y costar tanto dinero?" Mientras tanto, el equipo de desarrollo se frustra porque recibió 47 pedidos de cambio desde el inicio del proyecto, cada uno impactando el trabajo ya realizado.

Es aquí donde el Agile entra como solución, no apenas como metodología, sino como una transformación en la relación cliente-equipo. Imagina ahora que, en lugar de esperar tres meses para ver el producto, el cliente participa de reuniones semanales donde puede ver el software creciendo, como asistir a la construcción del coche en tiempo real.

En cada reunión, el cliente ve el progreso real: "Mira, implementamos el login que pediste. ¿Ah, quieres cambiar el color de los botones? Okay, pero eso significa que necesitaremos posponer la implementación del informe que estaba previsto para esta semana." El cliente pasa a entender que cada cambio tiene un impacto real en el desarrollo.

Esta transparencia trae tres beneficios fundamentales:

1. El cliente ve su dinero transformándose en producto cada semana, no apenas al final del proyecto.
2. Los cambios de requisitos son discutidos y priorizados en tiempo real, con entendimiento claro de los impactos.
3. El equipo puede adaptarse rápidamente a las necesidades más importantes del cliente, en lugar de seguir ciegamente un plan obsoleto.

El Agile no elimina cambios - los hace visibles y gestionables. Cuando el cliente dice "necesitamos cambiar esto", entiende que no está apenas cambiando una línea en un documento, sino redirigiendo el trabajo de personas reales que ve toda semana.

Este nuevo modelo de trabajo transforma la relación de "nosotros versus ellos" en una verdadera asociación. El cliente deja de ser un observador distante que juzga apenas el resultado final y se vuelve parte activa del proceso de desarrollo, entendiendo que cada decisión suya moldea no apenas el producto, sino también el camino para llegar hasta él.

Al final, el Agile no es sobre entregar software más rápido - es sobre entregar el software correcto, con total transparencia del proceso y de las decisiones que lo moldearon. Es sobre transformar el desarrollo de software de una caja negra misteriosa en un proceso colaborativo donde todos entienden los desafíos, costes e impactos de cada decisión.

Una frase para reflexionar... Para la empresa ella deja de trabajar con el contrato cerrado y comienza a trabajar con el contrato por tiempo.

Para la Empresa:

• Garantiza remuneración por el tiempo y expertise dedicados
• Se protege de cambios constantes de alcance
• Puede demostrar de forma clara el trabajo realizado
• Tiene flexibilidad para adaptar el equipo conforme necesidad

Para el Cliente:

• Mantiene el poder de decisión sobre prioridades llevando en consideración los consejos y las dependencias mostradas por la empresa.
• Visualiza el retorno de la inversión en ciclos cortos
• Puede ajustar el rumbo del proyecto pero sabrá de los impactos
• Paga por el valor efectivamente entregado

---

En la práctica, el desarrollo ágil funciona así:

• Entregas Incrementales
  • El producto es desarrollado en pequeños incrementos funcionales
  • Cada incremento entrega valor real al cliente
  • Ciclos cortos de desarrollo (generalmente 1-4 semanas)
• Colaboración Constante
• Equipos auto-organizables
• Comunicación diaria entre miembros del equipo
• Cliente participa activamente del desarrollo
• Feedback continuo y adaptación
• Flexibilidad a Cambios
• Planificación adaptativa
• Aceptación de que requisitos pueden cambiar
• Priorización continua basada en el valor para el negocio

El backlog es la lista de tareas de lo que necesita hacerse. Está en constante actualización y las tareas van ganando prioridades a lo largo del tiempo.

• Prácticas Comunes:

  • Daily Meetings (Reuniones Diarias) son para discutir lo que cada uno hizo ayer y va a hacer hoy. Si tiene algo que está bloqueando la tarea y lo que es necesario hacer para seguir adelante. Esta es una reunión rápida, solo para mostrar al cliente un poco de progreso y sincronizar el equipo.
  • Sprint Planning (Reunión de planificación de un ciclo). Parte de las tareas del backlog serán resueltas en el ciclo propuesto.
  • Sprint Review (Revisión del ciclo). Al final del ciclo es normal hacer una reunión para discutir tareas que quedaron pendientes y los motivos.
  • Retrospectivas. A veces es hecho en la misma reunión de review para alinear las cosas entre el equipo y discutir mejoras mejoras en el proceso.
  • Backlog Refinement (Refinamiento del Backlog). No siempre todas las tareas que están en el backlog son viables entonces descartamos unas, incluimos otras y ponemos prioridades. Generalmente las más prioritarias van para los ciclos.

• Papeles Típicos:

  • Product Owner (Dueño del Producto). La persona que controla los ítems del backlog y prioriza las cosas. Claro que para priorizar las cosas es necesario entender las dependencias entre ellas. Esta persona puede ser el cliente que conversa con el líder del equipo para dar una dirección, pero también puede ser una persona dedicada para eso.
  • Team Leader (en equipos Scrum acaba siendo el scrum master). Esta figura suele ser la persona con más conocimiento en el equipo. Puede ser un conocimiento técnico que ayudará al equipo a elegir las herramientas correctas y el mejor método de hacer las cosas, pero también puede ser conocer bien el negocio y entender las prioridades del backlog actuando como un product owner.
  • Equipo de Desarrollo

  Esas posiciones son bien variadas dependiendo del proyecto. Ya vi proyecto que el Tech Leader es el product owner, es el devops, es el arquitecto de cloud y hasta el desarrollador más experimentado. Las empresas no tienen dinero para estar contratando cada uno en su posición, el negocio es adelgazar costes. Pensar en el Tech Leader como el cabeza!

• Beneficios:

  • Mayor satisfacción del cliente
  • Reducción de riesgos
  • Detección precoz de problemas
  • Mejor calidad del producto
  • Mayor compromiso del equipo
  • Entregas más rápidas y frecuentes

El Agile no es apenas un conjunto de prácticas, sino una mentalidad que valora:

• Adaptación continua
• Aprendizaje constante
• Mejora iterativa
• Transparencia
• Colaboración efectiva

Metodologías

No voy a hablar sobre una metodología porque eso no hace más sentido. El Scrum tiene muchos rituales, papeles, que en la práctica no veo nadie queriendo gastar tanto con eso.

Lo que frecuentemente sucede en la práctica es una adaptación del Scrum, donde los equipos mantienen apenas los elementos que agregan valor real a su proceso. Es común ver equipos manteniendo:

Daily meetings (para alineamiento rápido) Sprints (para organización del trabajo) Product Backlog (para priorización)

Y simplificando o eliminando:

• Rituales extensos de planificación
• Largas retrospectivas formales
• Documentación excesiva
• Reglas rígidas de papeles

Esta adaptación es natural y hasta saludable, desde que mantenga los principios fundamentales del ágil

Un ejemplo práctico es un equipo que redujo la retrospectiva de 2 horas para un café de 30 minutos donde discuten mejoras de forma más natural y efectiva.

Lo importante no es seguir el Scrum al pie de la letra, sino encontrar el proceso que mejor funciona para tu equipo y tu contexto

Abajo las dos metodologías más conocidas.

Scrum Vs Kanban

Voy a explicar las principales diferencias entre Scrum y Kanban:

Característica	Scrum	Kanban
Ciclos de Trabajo	Sprints fijos (generalmente 2 semanas)	Flujo continuo, sin ciclos definidos
Papeles	Product Owner, Scrum Master, Equipo Dev	No define papeles específicos
Rituales	Daily, Planning, Review, Retrospectiva	No exige rituales específicos
Planificación	Compromiso con entregas del Sprint	Planificación continua y flexible
Métricas	Velocidad del equipo, Burndown	Lead time, Tiempo de ciclo
Limitación de Trabajo	Basado en la capacidad del Sprint	WIP Limits (límite de trabajo en progreso)
Alteraciones en el Ciclo	Idealmente no cambia durante el Sprint	Permite cambios en cualquier momento
Cuadro	Limpio a cada Sprint	Continuo, sin reset
Estimaciones	Story Points, Planning Poker	Opcional, enfoque en el tamaño de los ítems
Priorización	Product Backlog ordenado	Visual por columnas y swimlanes
Recomendado para	Proyectos con alguna previsibilidad	Servicios continuos (mantenimiento, soporte)
Entregas	Al final de cada Sprint	Continuas, conforme conclusión
Reuniones	Ceremonias fijas y timeboxed	Bajo demanda
Visual del Proceso	Columnas del Sprint	Flujo del trabajo completo
Documentación	Product/Sprint Backlog, Incremento	Políticas explícitas del cuadro

Veo que al final las empresas usan el Scrumban, un enfoque híbrido que coge un poco de cada metodología. Llamo esto de "El Scrumban de la Vida Real".

La Daily se mantiene diariamente y rápida.

Algunos rituales del Scrum (Daily, Planning, Review y Retro) se mantienen, así como la idea del backlog. Sin embargo, este último queda disponible en una columna del cuadro Kanban, con las prioridades definidas por la ordenación de los cards (que son las tareas).

El concepto de Sprint se transforma en un ciclo de reuniones para Planning y Review que, en la práctica, suceden juntas, generalmente cada dos semanas, pero el flujo de trabajo permanece continuo.

Se enfatiza el concepto de Épica, que representa la meta u objetivo con tiempo determinado - generalmente 2 o 3 meses - variando de acuerdo con lo que necesita implementarse.

El proceso se vuelve más equilibrado, evitando tanto la micro gestión impuesta por el Scrum como la flexibilidad excesiva del Kanban, encontrando así un término medio pragmático.

Priorización del Backlog

Voy a explicar el concepto de priorización L1, L2, L3 y L4, L5 y L6 en el contexto ágil de forma clara.

En el contexto ágil, los niveles L1 a L4 son una forma de categorizar la prioridad y severidad de diferentes ítems (como bugs, incidentes o tareas). Generalmente, una tarea viene con su prioridad definida para saber lo que debemos coger o no primero para hacer.

L1 (Prioridad Crítica)

• Impacto severo que afecta funciones críticas del negocio
• Requiere acción inmediata, generalmente en cuestión de horas

Ejemplo: Sistema completamente fuera del aire, imposibilitando operaciones esenciales Generalmente involucra movilización del equipo incluso fuera del horario comercial

L2 (Prioridad Alta)

• Impacto significativo, pero sin paralizar completamente las operaciones
• Necesita resolución rápida, típicamente dentro de 24-48 horas

Ejemplo: Funcionalidad importante con defecto, pero existe un contorno temporal Equipo prioriza esa actividad pudiendo reorganizar otras tareas.

¡Aquí está uno de los motivos que no da para aplicar el Full scrum, pues siempre suceden problemas que interfieren en el sprint!

L3 (Prioridad Media)

• Impacto moderado en las operaciones
• Puede resolverse dentro de una semana o en el próximo sprint

Ejemplo: Bug en función no crítica o mejoras importantes pero no urgentes Es planificado normalmente en el backlog del próximo sprint y generalmente ¡salta la fila!

L4 (Prioridad Baja)

• Impacto mínimo en el negocio
• Puede aguardar algunos sprints para ser resuelto

Ejemplo: Mejoras cosméticas u optimizaciones menores Entra en el backlog normal del producto para priorización futura

L5 (Prioridad Muy Baja)

• Mejoras cosméticas no urgentes
• Optimizaciones menores que no afectan la experiencia del usuario
• Tareas que pueden esperar meses para ser implementadas
• Ideas para futuras versiones del producto

Ejemplo: Cambio en el color de un icono no crítico, reformatación de código que ya funciona

L6 (Prioridad Mínima)

• Deseos o "nice to have"
• Ítems del backlog que pueden nunca ser implementados
• Ideas para ser consideradas en un futuro distante

Ejemplo: Refactorización de código que ya funciona bien, cambios puramente estéticos

---

En la mayoría de las organizaciones, ítems clasificados como L5 o L6 frecuentemente acaban siendo:

• Removidos del backlog después de un tiempo
• Reclasificados para una prioridad mayor si ganan importancia
• Mantenidos apenas como referencia para futuras discusiones

Por eso, la mayoría de las empresas trabajan apenas con la escala L1 a L4, que ya es suficiente para categorizar adecuadamente las prioridades de los ítems de trabajo.