Hoy quiero hablarte de Agile, Scrum y Kanban, porque sé que muchos ven esos nombres y solo repiten palabritas sin entender qué hay detrás. Y, además, tarde o temprano te las vas a encontrar en una entrevista de trabajo.
Cuando expliqué esto a mis alumnos de backend PHP me di cuenta de que necesitaban más que definiciones formales: querían entender por qué estas metodologías existen, qué sentido tienen, y también qué limitaciones esconden.
Un poco de historia para entender el porqué
Hace más de 20 años un grupo de desarrolladores se juntó en una estación de esquí en Utah para romper con el modo tradicional y lento de hacer software. Surgió el Manifiesto Ágil, que dijo básicamente: “basta de planificaciones eternas y procesos rígidos que no permiten cambios, queremos algo más humano, flexible y rápido.”
Así nacieron los valores de Agile:
- Priorizar a las personas y su interacción, no las herramientas.
- Entregar software funcionando en ciclos cortos, no esperar al final.
- Colaborar con el cliente, no pelearse con contratos.
- Adaptarse al cambio, no seguir planes rígidos a rajatabla.
Por eso en desarrollo decimos que:
Agile es más una forma de pensar que un conjunto de reglas.
No es un manual con pasos fijos ni un checklist. Agile es la filosofía que te dice: “Sé flexible, colabora, entrega valor rápido y no te cases con el plan.”
Si bien hay que reconocer que en estos 24 años de vida de Agile, el humo, la palabrería y la pose han ido encorsetando y difuminando la intención original. Algunas empresas parecen más ashrams tecnológicos que organizaciones que realmente desarrollan soluciones para sus clientes, terminando por desesperar a éstos frente a los continuos incumplimientos contractuales. Porque sí, los contratos siguen existiendo, a pesar de las buenas intenciones. Son necesarios, de hecho; sin ellos, nadie tendría claro qué debe cumplir formalmente en una relación.
Y en otras empresas ágiles hay más miedo que colaboración. Lo he visto. Los junior temen opinar, proponer o salirse del cajón de arena porque saben que las consecuencias son: más responsabilidades y presión para ellos; críticas del Scrum Master o de los seniors; y, en ocasiones, miradas condescendientes —la peor de las tres situaciones.
Porque en la vida no hay blancos ni negros, sino una multitud de grises y colores intermedios.
Esta crítica, personal, por cierto, no desacredita en absoluto la metodología Agile. Desacredita a quienes, tras la etiqueta, esconden orgullo y más “tradicionalismo” que el que puedas encontrar en El Corte Inglés.
Scrum: la forma en que las empresas intentan poner orden… y a veces, poner cadenas
Scrum es el marco más popular para aplicar Agile. Tiene cosas muy buenas: sprints que ayudan a dividir el trabajo en metas parciales (esas “metas volantes” o “objetivos parciales” que son mucho más manejables), roles claros, reuniones diarias que mantienen a todos en sintonía.
Pero aquí va mi opinión honesta (y la de muchos expertos): Scrum es también la forma en que las empresas intentan meter a presión el caos controlado de Agile.
- Los sprints son periodos fijos en los que el equipo se compromete a hacer ciertas tareas. Esto da ritmo, pero también limita tu capacidad para reaccionar rápido si cambia algo urgente.
- Las reuniones y roles pueden volverse burocracia si no se gestionan bien.
- Scrum pone reglas para que Agile sea predecible y medible, pero a veces sacrifica la flexibilidad y creatividad que Agile propone.
Por eso digo que Scrum puede “encorsetar” Agile, lo que no es malo ni bueno en sí mismo, solo es algo a tener en cuenta para que no pierdas la esencia ágil.
Kanban: el método visual que deja fluir las tareas sin encorsetarte
Kanban es diferente: no tiene ciclos fijos ni roles obligatorios. Solo un tablero donde ves el estado de cada tarea (Pendiente -To Do-, En proceso -In Progress-, Hecho -Do It-) y un límite para no saturar el equipo con demasiadas tareas simultáneas.
Esto es como manejar el tráfico para que no haya atascos. Kanban deja la puerta abierta para cambiar prioridades todo el tiempo y mantiene la flexibilidad que Agile quería.
Entonces, ¿cuál es la diferencia real?
- Agile es la filosofía, el porqué.
- Scrum es la receta con pasos y horarios que muchas empresas usan para hacer Agile más “controlable”.
- Kanban es una herramienta visual que permite fluir sin tanto protocolo.
¿Y qué pasa cuando en una entrevista te preguntan sobre Agile o Scrum?
No te limites a repetir términos. Explica que Agile busca adaptabilidad y colaboración, que Scrum ayuda a organizar el trabajo pero puede ser rígido y que Kanban es más flexible y visual.
Puedes usar esta metáfora o cualquier otra, lo importante es entender el concepto y saber adaptarte al ritmo frenético (y divertido) que supone trabajar bajo una metodología Agile:
- Agile es como bailar libremente con la música.
- Scrum es bailar una coreografía con pasos y tiempos marcados.
- Kanban es como organizar la sala de baile para que todos avancen en su práctica sin choques ni molestarse mutuamente.
Conclusión y consejo para programadores backend PHP
Conocer las metodologías es clave, pero más importante es entender cuándo y cómo usarlas.
- Scrum puede ayudar a dar ritmo a proyectos grandes, pero no dejes que las reglas te quiten la capacidad de adaptarte.
- Kanban es genial para equipos que necesitan flexibilidad visual y control de flujo.
Y sobre todo, recuerda: la metodología es una herramienta, no una camisa de fuerza.
Existe para ser útil y facilitar, no para entorpecer.