Agile y Scrum: historia, creadores e ideas principales
Agile y Scrum describen cosas diferentes
Agile es un conjunto de valores y principios para desarrollar software aprendiendo de la experiencia y adaptándose al cambio. Scrum es un marco que proporciona al equipo una estructura concreta para realizar trabajo complejo. Su relación es estrecha, pero los términos no son intercambiables. Un equipo puede seguir principios ágiles sin utilizar Scrum, y programar reuniones de Scrum no garantiza que sea adaptable ni que produzca resultados útiles.
Una pregunta práctica aclara la diferencia: ¿qué debería ocurrir cuando el equipo descubre que su plan original ya no encaja con el problema? Un enfoque ágil considera la nueva información una razón para revisar el plan. Scrum establece oportunidades periódicas para inspeccionar el trabajo y realizar esos ajustes. Ninguno elimina la necesidad de un objetivo, criterio profesional o atención a la calidad.
Por qué hacía falta otro enfoque
Los proyectos de software suelen comenzar con conocimiento incompleto. A los usuarios puede costarles explicar una necesidad antes de ver una solución posible, mientras los desarrolladores pueden descubrir limitaciones técnicas solo al intentar implementarla. Si todos los requisitos se consideran definitivamente fijados al principio, es posible cumplir fielmente un plan que ya no conduce al producto más útil. Descubrir ese desajuste tarde encarece la corrección y aumenta las interrupciones.
La respuesta no fue abandonar la planificación, sino reducir la distancia entre decidir y saber si la decisión funcionó. En lugar de esperar una gran entrega final, los equipos podían crear resultados utilizables más pequeños, buscar opiniones y actualizar prioridades. Esta lógica se desarrolló mediante varios enfoques antes de que Agile se convirtiera en su nombre compartido. No apareció como la invención completa de una persona en un solo día.
Las raíces de Scrum preceden al Manifiesto Ágil
Un antecedente importante es el artículo de 1986 de Hirotaka Takeuchi e Ikujiro Nonaka, The New New Product Development Game. Su metáfora del rugby ayudó a entender el desarrollo de productos como movimiento coordinado del equipo en vez de una simple secuencia de traspasos. El artículo trataba el desarrollo de productos en sentido amplio; no debe confundirse con el posterior marco de software ya completamente definido.
Ken Schwaber y Jeff Sutherland desarrollaron Scrum a comienzos de los años noventa y lo presentaron conjuntamente en la conferencia OOPSLA de 1995. Se los reconoce como sus cocreadores, aunque otros profesionales también contribuyeron. La primera Guía Scrum apareció en 2010. El orden importa: Scrum existía antes del Manifiesto Ágil y después pasó a ser uno de los marcos más conocidos del desarrollo ágil.
La reunión de 2001 dio una identidad común a Agile
Del 11 al 13 de febrero de 2001, diecisiete profesionales del software se reunieron en Snowbird, Utah. Representaban enfoques diferentes, entre ellos programación extrema, Scrum y Crystal. Según el relato oficial de la reunión, buscaban puntos en común más allá de procesos pesados y centrados en documentos. El resultado fue el Manifiesto para el Desarrollo Ágil de Software, conocido como Manifiesto Ágil.
Los diecisiete firmantes fueron Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas. Agile tiene, por tanto, autoría colectiva. Los dos cocreadores de Scrum figuraban entre ellos, pero no se les puede atribuir en exclusiva el movimiento más amplio.
Cuatro valores con una precisión importante
El Manifiesto concede más peso a la colaboración humana que a la dependencia rígida de procedimientos, al software que funciona que a las descripciones exhaustivas, a una relación continua con el cliente que al regateo contractual y a adaptarse a nuevas circunstancias que a conservar mecánicamente un plan antiguo. Estas prioridades ayudan a resolver tensiones habituales en proyectos reales. No prohíben herramientas, contratos, documentación ni planes.
Esta precisión es esencial. Un producto regulado puede requerir documentación abundante; un equipo distribuido puede depender mucho de las herramientas. La pregunta es si apoyan el trabajo y a quienes necesitan sus resultados. Los doce principios complementarios incorporan entrega frecuente, trabajo sostenible, cuidado técnico y reflexión periódica. Agile pide examinar cómo se trabaja, no simplemente adoptar un vocabulario de moda.
Qué añade Scrum a esas ideas
Scrum organiza el trabajo alrededor de un equipo pequeño, una dirección de producto compartida y periodos repetidos llamados Sprints. Un Sprint dura como máximo un mes. Durante él, el equipo persigue un Objetivo del Sprint y crea una adición utilizable al producto. El ciclo corto limita cuánto tiempo permanecen sin examinar las suposiciones, siempre que se inspeccionen resultados de verdad y no se informe únicamente de actividad.
La Guía Scrum identifica tres responsabilidades. El Product Owner responde de maximizar el valor del producto y gestionar el Product Backlog ordenado. Los Developers crean el resultado utilizable y organizan su trabajo. El Scrum Master ayuda a establecer Scrum y mejorar la efectividad del equipo. No se define como un jefe que reparte tareas diarias, y el Product Owner es una persona, no un comité decisorio.
Un ciclo de trabajo, no solo un calendario de reuniones
La Sprint Planning establece por qué importa el próximo Sprint, qué puede asumir el equipo y cómo piensa proceder. Durante el Sprint, la Daily Scrum ofrece a los Developers quince minutos para inspeccionar el progreso hacia el objetivo y adaptar el plan. La Sprint Review examina el resultado con las partes interesadas y orienta el trabajo futuro. La Sprint Retrospective se centra en mejorar la colaboración del equipo.
Los eventos cumplen funciones diferentes. La Review no es simplemente una barrera de aprobación, y la retrospectiva no sirve para culpar a alguien de una semana difícil. Tampoco una reunión diaria resulta eficaz solo porque las personas estén de pie. El vínculo entre observación y acción importa más que la apariencia: al aparecer un obstáculo o una suposición equivocada, el equipo necesita una posibilidad real de responder.
Cómo se ve el enfoque en un producto corriente
Imaginemos un equipo que crea un sitio educativo. En vez de construir toda una plataforma de cursos antes de mostrar nada, podría entregar primero una experiencia de lección pequeña y utilizable. Los alumnos abren una lección, leen el contenido y la marcan como terminada. Sus comentarios pueden revelar que comprender el progreso importa más que el complejo panel inicialmente previsto. El descubrimiento puede cambiar el orden del trabajo posterior.
Es un ejemplo ilustrativo, no un proyecto histórico. Muestra dos ideas complementarias: el desarrollo incremental añade capacidades utilizables, mientras el iterativo revisa y mejora lo aprendido o construido. Un prototipo dedicado a explorar una idea puede ser valioso, pero no es automáticamente una adición terminada al producto. En Scrum, el trabajo debe cumplir la Definición de Terminado del equipo antes de formar parte de un Incremento completado.
Dónde encajan otras prácticas y personas
Agile va más allá de Scrum. La programación extrema enfatiza las prácticas de ingeniería de software; Kanban se centra en gestionar el flujo y limitar el trabajo en curso. Los equipos también pueden utilizar historias de usuario, técnicas de estimación o tableros visuales. Son apoyos posibles, pero Scrum no exige historias de usuario, puntos de historia ni póquer de planificación. Confundir una recomendación frecuente con una regla oficial hace parecer el marco más complicado de lo que es.
Después, formadores y autores ayudaron a difundir estas ideas. Mike Cohn, por ejemplo, aportó explicaciones influyentes sobre historias de usuario y planificación ágil, aunque no firmó el Manifiesto. CI/CD pertenece al ámbito técnico: integración frecuente, verificaciones automáticas y procesos fiables de publicación pueden apoyar ciclos cortos de retroalimentación. No es otro nombre de Agile ni un componente obligatorio de Scrum.
Qué debería significar el éxito
Agile y Scrum no prometen que cada proyecto sea fácil ni que todos los plazos sean acertados. Convierten la incertidumbre en algo gestionable mediante trabajo visible, opiniones y adaptación. Esto necesita condiciones externas a la sala de reuniones: acceso a usuarios, prioridades claras, capacidad de decidir y una atención sostenible a la calidad. Cambiar cargos sin transformar esas condiciones puede dejar intactos los problemas iniciales.
La prueba útil es concreta: ¿puede el equipo descubrir malentendidos antes, responder a las pruebas y producir algo utilizable? Un calendario ocupado y un tablero lleno no responden esa pregunta. Comprender la historia mantiene visible el propósito: Agile expresó prioridades compartidas, mientras Scrum ofreció una estructura para dar al aprendizaje y a la entrega coordinada un ritmo repetible.
