To understand the relationship between different agile approaches, it is essential to visualize them in a hierarchy. AgileAgileFilosofía de desarrollo de software basada en entregas iterativas, adaptabilidad al cambio, colaboración continua con el usuario e inspección frecuente en lugar de planes rígidos a largo plazo. represents the philosophy and the core values framework (adaptability, continuous delivery of value, and frequent inspection). On the other hand, frameworks like ScrumScrumFramework de trabajo adaptativo estructurado en ciclos fijos (Sprints), diseñado para abordar problemas complejos mediante roles definidos (Product Owner, Scrum Master, Developers), eventos ceremoniales y entregas incrementales de software funcional. and KanbanKanbanSistema visual de gestión de flujo de trabajo enfocado en la entrega continua, la optimización del tiempo de ciclo (cycle time) y la limitación del trabajo en curso (WIP limits) para evitar cuellos de botella sin depender de Sprints prefijados. are concrete implementations that establish rules, roles, and operational mechanics to execute that philosophy.
A very illustrative analogy to differentiate both frameworks is to imagine that Scrum works like a train with schedules, fixed stops, and coupled cars, while Kanban operates like a continuous flow highway where vehicles constantly move forward and traffic is regulated to avoid congestion.
If you wish to delve deeper into how these frameworks fit within the global architecture and engineering ecosystem, you can consult our guide on the Introduction to Design Methodologies.
1. The Scrum Framework
Scrum is an iterative and incremental framework designed to manage complex projects where requirements evolve rapidly. It is based on closed time-boxed cycles called SprintsSprintBloque de tiempo acotado (time-box), habitualmente de 1 a 4 semanas, en el que un equipo de desarrollo se compromete a completar un objetivo (Sprint Goal) y entregar un Incremento funcional de producto., which typically last from 1 to 4 weeks.
The Three Core Roles
- Product Owner: Acts as the voice of the business and end users. They are responsible for maximizing the product's value and managing the Product BacklogBacklogLista priorizada y dinámica que contiene todos los requisitos, funcionalidades, historias de usuario, refactorizaciones y correcciones pendientes de realizar en un proyecto de software., ensuring requirements are clearly defined and prioritized.
- Scrum Master: Responsible for facilitating framework adoption, removing technical or organizational impediments that block the team, and protecting the group from external interruptions.
- Developers: A multidisciplinary and self-organizing team responsible for transforming backlog items into a functional product Increment at the end of each cycle.
The Five Ceremonial Events
- Sprint: The temporary container where work is executed without altering the bounded strategic goal.
- Sprint Planning: Initial meeting where the Sprint Goal is defined and tasks that will make up the Sprint BacklogBacklogLista priorizada y dinámica que contiene todos los requisitos, funcionalidades, historias de usuario, refactorizaciones y correcciones pendientes de realizar en un proyecto de software. are selected.
- Daily Scrum: Daily synchronization event limited to 15 minutes to inspect progress toward the goal and identify blocks.
- Sprint Review: Session demonstrating the functional product at the end of the Sprint to stakeholders to collect immediate feedback.
- Sprint Retrospective: Space for internal team inspection to evaluate processes, tools, and work dynamics, applying continuous improvements.
The Three Artifacts
- Product Backlog: A single, dynamic source of truth containing all the project's features, enhancements, and bug fixes.
- Sprint Backlog: A set of tasks selected from the Product Backlog along with the plan to deliver them during the current Sprint.
- Increment: The sum of all backlog elements completed during the Sprint that strictly meet the Definition of Done (DoD) and are ready for production.
2. The Kanban Framework
Unlike Scrum, Kanban is not based on calendar-bounded iterations, but on the visual and continuous management of the workflow (flow-based). Its main objective is to optimize efficiency and minimize Lead Time (the time elapsed from when a task is requested until it is delivered to production).
Fundamental Principles of Kanban
- Workflow visualization: Use of boards divided into columns (To Do, In Progress, In Review, Done) to represent the actual state of each task.
- No mandatory roles: Kanban adapts to the team's existing structure. By not requiring fixed roles to cover ceremonial positions, it is a natural and practical methodology when managing developments, deployments, infrastructure, or configurations in a fully autonomous and independent manner.
- Limiting WIP (Work in Progress): Explicit restriction on the maximum number of simultaneous tasks allowed in a column (e.g., a limit of 3 tasks in "In Progress"). If the limit is reached, no new task can start until one of the existing ones is finished, preventing too many open fronts.
- Flexibility to changes: Allows responding to emergencies (server down, critical bug in production) by adding the task to the top of the pending column immediately.
3. Quick Comparative Matrix: Scrum vs Kanban
To analyze the practical implications and risks of rigidly applying these frameworks in real environments, consult our experience reflection: When applications rule our methodologies.