# Scrum para No-Tecnicos: Como Funciona el Desarrollo Agil (y Por Que te Importa)
Cuando contratas una empresa de software, tarde o temprano escucharas terminos como "sprint", "backlog", "daily standup" o "retrospectiva". Si vienes del mundo empresarial tradicional, es posible que esas palabras suenen a jerga tecnica innecesaria. No lo son.
Entender como funciona Scrum —aunque sea a nivel conceptual— es una ventaja real como cliente. Te permite participar mejor en el proyecto, anticipar problemas antes de que se vuelvan costosos y tomar decisiones más informadas sobre prioridades y presupuesto.
Este artículo explica Scrum en lenguaje de negocio, sin asumir que sabes programar.
---
Tabla de Contenidos
- Por que el modelo en cascada falla en desarrollo de software
- Que es Scrum y de donde viene
- Los tres roles: quien hace que
- El backlog: la lista maestra de todo lo que se va a construir
- Los sprints: como avanza el trabajo
- Las ceremonias: las reuniones que si importan
- Como participar como cliente sin perderte
- FAQ
---
Por Que el Modelo en Cascada Falla en Desarrollo de Software
El modelo en cascada (waterfall) funciona bien para construir un puente: primero se disena, luego se obtienen permisos, luego se construye. No tiene sentido empezar a poner concreto mientras el diseño sigue cambiando.
El desarrollo de software es fundamentalmente diferente. Los requisitos cambian porque:
- El negocio evoluciona durante el tiempo que toma el proyecto
- Los usuarios descubren lo que realmente necesitan cuando ven el primer prototipo, no cuando firman el requerimiento
- El mercado se mueve y lo que era prioridad en enero puede no serlo en julio
El resultado clásico del modelo en cascada en software: 12 meses despues, el equipo entrega exactamente lo que se específico al inicio, y la empresa se da cuenta de que la mitad de eso ya no es relevante y le falta la mitad de lo que en realidad necesita.
Un estudio de Standish Group (Chaos Report) muestra consistentemente que entre el 30% y el 40% de las funcionalidades de software nunca o casi nunca se usan. En proyectos waterfall, todas esas funcionalidades se pagan de igual forma.
Scrum existe para evitar exactamente ese problema.
---
Que es Scrum
Scrum es un marco de trabajo (framework) para desarrollar productos complejos en ciclos cortos e iterativos, incorporando retroalimentacion real del cliente despues de cada ciclo.
La premisa es simple: en lugar de planear todo al inicio y entregar al final, se entrega valor funcional cada 2-4 semanas. Cada entrega es pequena pero real, y el cliente puede verla, probarla y ajustar la dirección antes de que el equipo avance.
En lugar de "dame todo lo que necesitas en 6 meses", Scrum propone "dime que necesitas primero, te lo entregamos en 2 semanas, me dices si va bien y continuamos".
---
Los Tres Roles: Quien Hace Que
Product Owner (Dueno del Producto)
Este es el rol mas importante para la empresa cliente. El Product Owner es la persona responsable de definir QUE se construye y en que orden. Representa los intereses del negocio frente al equipo técnico.
Sus responsabilidades principales:
- Mantener y priorizar el backlog (la lista de lo que se va a construir)
- Estar disponible para resolver dudas del equipo sobre requisitos
- Aprobar (o rechazar) el trabajo completado al final de cada sprint
En proyectos donde iTechDev es el proveedor, el Product Owner suele ser un directivo o gerente de la empresa cliente. Si no hay un Product Owner disponible o empoderado para tomar decisiones, el proyecto tendra problemas independientemente de que tan bueno sea el equipo técnico.
Scrum Master
Es el facilitador del proceso. Se asegura de que el equipo pueda trabajar sin obstaculos: elimina bloqueos, facilita las reuniones y protege al equipo de interrupciones externas. No es el jefe del equipo ni el gerente del proyecto en el sentido tradicional.
Equipo de Desarrollo
Los desarrolladores, disenadores y especialistas que construyen el producto. En Scrum son auto-organizados: deciden entre ellos como llevar a cabo el trabajo, no se les asignan tareas individualmente desde afuera.
---
El Backlog: La Lista Maestra
El Product Backlog es una lista priorizada de todo lo que el producto necesita. Cada elemento se llama "historia de usuario" (user story) y se escribe desde la perspectiva del usuario:
"Como gerente de ventas, quiero ver un reporte de ventas por region para identificar rapidamente cuales zonas estan por debajo del objetivo."
Esta forma de escribir requisitos tiene una razon: obliga a conectar cada funcionalidad con un beneficio real para alguien, no solo con una especificacion tecnica.
El backlog nunca esta "terminado". Se actualiza continuamente conforme el negocio aprende, el mercado cambia y los usuarios dan retroalimentacion. Esto es una caracteristica, no un defecto.
La prioridad del backlog la define el Product Owner, no el equipo técnico. El equipo estima el esfuerzo necesario para cada elemento; el Product Owner decide en que orden se trabajan en funcion del valor de negocio.
---
Los Sprints: Como Avanza el Trabajo
Un sprint es un ciclo de trabajo de duracion fija, generalmente 2 semanas. Al inicio del sprint, el equipo selecciona del backlog los elementos que puede completar en ese período y se compromete a entregarlos.
Al final del sprint:
- Las funcionalidades seleccionadas deben estar terminadas y listas para usar (o al menos para ser demostradas)
- El cliente las revisa en una sesion formal llamada Sprint Review
- El equipo reflexiona sobre como mejorar su proceso en la Retrospectiva
- Empieza el siguiente sprint
Lo que no se completa en un sprint no se "arrastra" automaticamente. El Product Owner decide si va de regreso al backlog o si toma prioridad en el siguiente sprint.
Este ciclo tiene un efecto importante para el cliente: cada 2 semanas tienes una version del producto que puedes ver y tocar. Si algo no va en la dirección correcta, lo detectas rápido, no despues de 6 meses.
---
Las Ceremonias: Las Reuniones que si Importan
Scrum tiene cuatro reuniones formales. Cada una tiene un propósito específico y un tiempo limite:
Sprint Planning (Planeacion del Sprint)
Al inicio de cada sprint. El equipo y el Product Owner acuerdan que se va a construir en las proximas dos semanas. Duracion: 2-4 horas para sprints de 2 semanas.
Daily Standup (Reunion Diaria)
15 minutos al inicio de cada dia. Cada miembro del equipo responde tres preguntas: que hice ayer, que voy a hacer hoy, hay algo que me esta bloqueando. No es una reunion de reporte, es de coordinacion.
Sprint Review (Revision del Sprint)
Al final del sprint. El equipo demuestra lo que construyo al Product Owner y stakeholders relevantes. Es una demo de funcionalidades reales, no una presentación de PowerPoint. El cliente puede usar el sistema, hacer preguntas y dar retroalimentacion directa.
Sprint Retrospective (Retrospectiva)
También al final del sprint, pero enfocada en el equipo: que salio bien, que salio mal, que vamos a mejorar en el siguiente sprint. Esta reunion es interna del equipo; el cliente generalmente no participa.
---
Como Participar Como Cliente Sin Perderte
Estos son los habitos que hacen que un proyecto Scrum funcione bien desde el lado del cliente:
1. Sé el Product Owner o designa a alguien que pueda serlo. Necesitas una persona con autoridad para tomar decisiones de prioridad y disponibilidad para responder preguntas del equipo en menos de 24 horas. Si las decisiones requieren aprobacion de tres niveles jerarquicos, el equipo se bloqueara constantemente.
2. Asiste a cada Sprint Review. Esta es la reunion donde mas valor como cliente. Si no puedes asistir, al menos ve la grabacion y envia retroalimentacion escrita antes de que empiece el siguiente sprint.
3. Prioriza con criterio de negocio, no de preferencia personal. "Primero quiero el módulo de reportes porque me parece mas interesante" es diferente a "primero el módulo de reportes porque sin el no puedo tomar decisiones de compra". La segunda justificacion conduce a mejores decisiones de backlog.
4. Acepta que los requisitos van a cambiar. En Scrum, cambiar de opinion no es un problema; es parte del proceso. Lo que no es aceptable es cambiar de opinion dentro del sprint (mientras el equipo esta construyendo). Los cambios van al backlog y se incorporan en el siguiente sprint.
5. No le asignes trabajo directamente a los desarrolladores. Todo pasa por el Product Owner y el backlog. El equipo necesita un solo punto de entrada de prioridades, no cinco jefes dandole instrucciones simultaneas.
---
FAQ
¿Scrum garantiza que el proyecto termine a tiempo y dentro del presupuesto?
No. Ningun método lo garantiza. Lo que Scrum garantiza es visibilidad: cada 2 semanas sabes exactamente donde estas, que se ha completado y cuanto falta. Si el proyecto va a tener problemas de tiempo o presupuesto, los detectas en el sprint 3, no en el mes 11.
¿Cuantas personas necesito dedicar al proyecto como cliente?
El mínimo es un Product Owner que pueda dedicar entre 4 y 8 horas semanales al proyecto. Mas tiempo que eso es mejor. Si no tienes a nadie disponible, el proveedor puede asumir el rol de Product Owner, pero eso reduce tu control sobre las prioridades del producto.
¿Que pasa si mi proyecto tiene una fecha de entrega fija (un evento, una auditoria, un lanzamiento)?
Scrum no impide tener fechas fijas. Cambia lo que es negociable: en lugar de ajustar el tiempo, ajustas el alcance. Si el sprint 10 llega y no todo el backlog esta completado, decides que funcionalidades son indispensables para la fecha y cuales pueden esperar a una segunda fase.
¿Scrum funciona para proyectos pequenos de 2-3 meses?
Si, aunque para proyectos muy cortos (menos de 4 semanas) puede ser más eficiente un enfoque Kanban. En iTechDev adaptamos el marco de trabajo al tamaño y contexto del proyecto.
---
Siguiente Paso
Cuando un proyecto de software falla, pocas veces es por falta de habilidad tecnica. La mayoria de las veces, falla por falta de comunicación, cambios de requisitos mal gestionados y entregas que llegan demasiado tarde para corregir el rumbo.
En iTechDev trabajamos con metodologias agiles adaptadas al contexto de cada cliente. Si estas por iniciar un proyecto de software o quieres evaluar si tu proyecto actual va bien, agenda una sesion sin costo con nuestro equipo.
Habla con nosotros: meet.itechdev.com.mx/itechdev/consulta