Metodologías Ágiles Aplicadas al Desarrollo a Medida

Casi todos los proyectos de software empresarial moderno usan algún tipo de metodología ágil: Scrum, Kanban, ScrumBan o variantes. Cómo se aplica agile en desarrollo de software a medida, qué ceremonias importan, qué métricas trackear, y los errores típicos que diferencian agile real de agile teatral.

Para contexto, leé cómo desarrollar software a medida en 7 etapas y qué es un MVP y cuánto tarda.

Por qué agile vs waterfall

Waterfall (el modelo viejo)

Define todo upfront → diseña → desarrolla → testea → entrega al cliente al final. Si algo cambia en el camino, costoso. Si lo entregado no era lo que el cliente esperaba, peor.

Agile (el modelo actual)

Itera en sprints cortos. Cada sprint tiene un objetivo, entrega valor, recibe feedback, ajusta para el siguiente. El cliente ve progreso continuo y puede cambiar prioridades en cada sprint.

Por qué agile gana en software empresarial

1. Los requerimientos cambian. En 2-4 meses de desarrollo, el negocio cambia. Agile absorbe cambios.
2. El cliente aprende usando el software. Lo que pidió en mes 1 puede no ser lo que necesita en mes 4. Demos quincenales evitan sorpresas.
3. El riesgo se distribuye. Big bang al final puede explotar. Releases continuos validan continuamente.
4. Mejor calidad. Tests + feedback + iteración producen mejor software que diseño exhaustivo seguido de desarrollo apurado.

Scrum

Estructura

• Sprints fijos de 1-4 semanas (normalmente 2)
• Backlog priorizado de tareas
• Sprint backlog con tareas comprometidas para el sprint actual

Roles

• Product Owner. Por parte del cliente. Prioriza el backlog, define qué va al sprint, valida demos.
• Scrum Master / Tech Lead. Por parte de la agencia. Facilita ceremonias, destraba bloqueos, protege al equipo.
• Equipo de desarrollo. 2-6 personas: devs, QA, eventualmente UX.

Ceremonias

Sprint Planning (lunes 1)

• 1-2 horas
• Equipo + PO
• Revisar backlog priorizado, seleccionar tareas para el sprint, estimar effort

Daily Standup

• 15 minutos diarios
• Solo equipo dev (PO opcional)
• Cada uno responde: ¿qué hice ayer? ¿qué hago hoy? ¿blockers?

Sprint Review / Demo (viernes 2)

• 1-2 horas
• Equipo + PO + stakeholders
• Demo de lo construido, recibir feedback, ajustar para próximo sprint

Sprint Retrospective (viernes 2)

• 1 hora
• Solo equipo
• Qué funcionó, qué no, qué cambiar para próximo sprint

Artefactos

• Product Backlog. Lista priorizada de todas las tareas pendientes (puede tener 50-200 ítems).
• Sprint Backlog. Lista de tareas comprometidas para el sprint actual (8-20 ítems típicos).
• Increment. El producto funcional al final del sprint.

Kanban

Estructura

• Sin sprints fijos - flujo continuo
• Tablero con columnas: Backlog → To Do → In Progress → Review → Done
• WIP limits - máximo de tareas en cada columna

Cuándo usar

• Equipos de mantenimiento (bugs + ajustes constantes)
• Proyectos con prioridades muy cambiantes
• Equipos chicos donde Scrum es overkill

Métricas

• Lead time: desde que entra a backlog hasta que está done
• Cycle time: desde que entra a "In Progress" hasta done
• Throughput: cantidad de tareas done por semana

ScrumBan (recomendado para pyme)

Es el modelo que usamos en proyectos de sistemas a medida cuando el cliente necesita previsibilidad sin perder flexibilidad. Híbrido pragmático: estructura de Scrum (sprints quincenales, demos, retros) + flexibilidad de Kanban (WIP limits, prioridad cambiable mid-sprint).

Por qué funciona en pyme argentina

• Sprints quincenales dan ritmo y previsibilidad
• WIP limits previenen overload del equipo
• Prioridad ajustable absorbe urgencias del cliente
• Ceremonias livianas no consumen mucho tiempo

Cómo lo aplica Skyma IT

1. Sprint planning quincenal (lunes lunes): equipo + cliente revisa backlog, elige tareas para 2 semanas
2. Daily standup (lunes a viernes, 15 min): solo equipo dev
3. Demo viernes 2 con cliente: validación + feedback
4. Retro corta viernes 2: 30 min equipo
5. Backlog grooming (semanal): refinar y priorizar

Errores típicos al implementar agile

1. Agile teatral sin participación del cliente

Equipo dev hace todas las ceremonias correctamente pero el cliente nunca participa de demos ni planning. Resultado: software se construye basado en supuestos, falla en review final. Solución: cláusula contractual de participación mínima del cliente.

2. Sprint planning sin priorización clara

"Todo es prioridad alta" → equipo decide por su cuenta → conflictos en review. Solución: Product Owner debe priorizar backlog antes del planning.

3. Daily standup que dura 45 minutos

Convertido en reunión de coordinación + debate técnico. Solución: estricto 15 minutos, lo técnico se discute después con quien aplique.

4. Sin retros o retros sin acción

Retrospective se hace pero no se cambia nada. Solución: cada retro elige 1-2 mejoras concretas para próximo sprint.

5. WIP overload

Equipo trabajando en 8 tareas simultáneas, ninguna avanza. Solución: WIP limit estricto (máximo 1.5 tareas por persona en in-progress).

6. Estimaciones que se ignoran

Equipo estima 8 puntos por sprint, cliente exige 15, equipo se quema. Solución: respetar capacidad demostrada por velocity histórico.

7. Cero documentación

"Agile = sin documentación" es un mito. Sin documentación técnica básica (modelo de datos, decisiones de arquitectura, runbooks), el equipo nuevo no puede tomar el código. Solución: documentar lo crítico, no todo.

Métricas que importan

Velocity

Puntos de historia o tareas completadas por sprint. Útil después de 3-4 sprints para predecir capacidad.

Lead Time

Tiempo desde que una tarea entra al backlog hasta que está en producción. Si crece, hay backlog inflado o capacity issue.

Cycle Time

Tiempo desde que se empieza a trabajar una tarea hasta done. Si es alto, hay tareas demasiado grandes o muchos blockers.

Bug Rate

Cantidad de bugs reportados / cantidad de features entregadas. Indicador de calidad.

Adoption Rate (post-go-live)

% del equipo cliente usando el sistema. Métrica clave para validar éxito.

Tooling

Linear (recomendado)

Modern, rápido, con keyboard shortcuts. Free hasta 250 issues, paid USD 8/usuario/mes.

Jira

Default enterprise. Más complejo pero potente. USD 7-13/usuario/mes según plan.

GitHub Projects

Si ya usás GitHub, integrado directamente. Gratis hasta cierto punto.

Azure DevOps

Default Microsoft. Buen para empresas en stack MS.

Para gestión de tareas + comunicación con cliente

Linear o Jira para tracking interno + Slack/Teams para comunicación + Loom para demos asíncronas.

Escenario real

Una empresa argentina contrató a Skyma IT para sistema de gestión clínica. Equipo: 3 devs + 1 QA + 1 PM/TL. Cliente: 1 founder + 1 referente operativo (gerente clínica).

Setup inicial

• Sprints quincenales
• Linear para tracking
• Slack para comunicación
• Demo + retro cada 2 semanas

Sprint planning del cliente

• Lunes 1: planning de 90 min con cliente. Selección de 12-18 issues.
• Estimación en t-shirt sizes (XS, S, M, L)

Sprint en ejecución

• Daily 15 min, solo equipo dev
• Cliente disponible en Slack para preguntas
• Acceso a build de stage 24/7 para validación temprana

Demo + retro viernes 2

• 60 min demo con cliente
• 30 min retro interna del equipo
• Decisiones documentadas en Linear

Resultado

• 6 sprints (12 semanas) para MVP completo
• Adopción cliente 100% al sprint 3 (ya usaban en producción)
• Cero overlapping con Excel desde sprint 6
• Bug rate: 0.3 bugs por feature entregada (industry avg: 0.7-1.5)

Cómo evaluar si una agencia hace agile bien

Preguntas a hacer

1. ¿Cómo organizan sprints? Buscar duración fija (2 semanas típicas), planning + review + retro estructurado.
2. ¿Cuánta participación del cliente esperan? Buscar respuesta concreta (ej: 4-6 horas/semana).
3. ¿Qué tooling usan? Linear, Jira, GitHub Projects son razonables. Excels y emails son alerta.
4. ¿Demos quincenales o solo al final? Quincenales no negociable.
5. ¿Cómo manejan cambios de scope mid-sprint? Buscar respuesta razonable (re-priorización en próximo sprint, no rechazo total).

Red flags

• Cero ceremonias
• Demos solo al final del proyecto
• "Agile" pero entregables sólo en mes 6
• Sin tooling de tracking visible al cliente
• Cliente recibe estimaciones rígidas tipo waterfall

Para llevarse

Agile en desarrollo de software a medida 2026 es ScrumBan en práctica: sprints quincenales con disciplina, ceremonias livianas, participación activa del cliente. La diferencia entre proyectos exitosos y proyectos fallidos suele ser la calidad de la implementación de agile más que el stack técnico.

Como cliente, exigir demos quincenales con participación de tu equipo + tooling visible (Linear/Jira) + ceremonias estructuradas + métricas trackeadas es la receta para evitar agile teatral.

Necesitás esto en tu empresa? Hablemos. Lecturas: cómo desarrollar software a medida en 7 etapas, qué es un MVP, stack tecnológico para sistemas empresariales 2026.