Agile vs Kanban
What are Agile and Kanban?
Agile is a philosophy for software development defined by the Agile Manifesto of 2001. It prioritizes individuals over processes, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Agile is not a specific methodology -- it is a set of values and principles that inform various concrete frameworks, including Scrum, Kanban, XP, and others.
Kanban is one such framework. Originating from Toyota's manufacturing processes, Kanban focuses on visualizing the workflow, limiting the amount of work in progress at any stage, and optimizing the flow of work items from start to completion. Unlike Scrum, Kanban does not prescribe sprints, ceremonies, or roles. It is a continuous flow system where work is pulled as capacity becomes available.
Why does it matter?
Choosing the wrong development methodology wastes time and frustrates teams. A team forced into rigid two-week sprints when their work consists of unpredictable support requests and urgent fixes spends more time in sprint planning and estimation than in productive work. Conversely, a team building a complex product without any structured iteration risks losing focus and delivering nothing of value for months.
Scrum -- the most popular Agile framework -- organizes work into fixed-length sprints (typically two weeks). Each sprint begins with planning, ends with a review and retrospective, and the team commits to delivering a defined scope. This structure provides predictability: stakeholders know what will be delivered and when. It works well for product development teams with a clear roadmap and the ability to plan work in advance.
Kanban suits teams with a continuous stream of work that does not fit neatly into sprints. Operations teams, support teams, DevOps teams, and maintenance-focused development teams benefit from Kanban's flow-based approach. There is no sprint commitment -- work items enter the backlog, are pulled into active columns when capacity is available, and move through stages until completion. The key metric is cycle time (how long a work item takes from start to finish) rather than velocity (how many story points are completed per sprint).
For many development teams, the right answer is neither pure Scrum nor pure Kanban, but a hybrid. "Scrumban" combines Scrum's iteration structure with Kanban's WIP limits and flow metrics. Teams plan in iterations but allow work to flow continuously within them. This pragmatic middle ground avoids the rigidity of strict Scrum and the lack of structure in pure Kanban.
The methodology also affects how teams handle technical debt. Scrum teams can allocate a percentage of each sprint to debt reduction. Kanban teams can use swim lanes or card types to ensure maintenance work flows alongside feature work. Both approaches work -- the key is that debt reduction is built into the workflow rather than perpetually deferred.
Agile and Kanban in practice
A typical Kanban board has columns representing workflow stages: Backlog, Ready, In Progress, In Review, Testing, Done. Each column except Backlog and Done has a WIP limit -- for example, the "In Progress" column might be limited to three items. When a developer finishes a task, they pull the next item from the "Ready" column. If the "In Progress" column is at its limit, no new work can be started until something moves forward. This constraint prevents context switching -- one of the most significant productivity killers in software development.
In practice, a development team working on a SaaS product might use the following setup: product features are planned in two-week cycles (borrowed from Scrum), while bug fixes and operational tasks flow through a Kanban board with no sprint boundaries. The team tracks both velocity for planned work and cycle time for unplanned work, giving stakeholders visibility into both streams.
Code reviews fit naturally into the workflow as a board column. A WIP limit on the review column ensures that pull requests do not languish -- if the review queue is full, developers review existing PRs before starting new work. This feedback loop keeps code moving through the CI/CD pipeline and prevents bottlenecks.
The development subscription model aligns particularly well with Kanban. Clients maintain a prioritized backlog, and the development team pulls work continuously. Deliverables flow steadily rather than arriving in sprint-sized batches. Priorities can be adjusted at any time without disrupting a sprint commitment. This flexibility is especially valuable for startups and scaling companies whose priorities shift frequently.
Related concepts
- Code Review -- A workflow step managed within Agile and Kanban processes
- CI/CD Pipeline -- Automated delivery that complements iterative development
- Technical Debt -- Managing debt within Agile workflows
- Development Subscription Model -- Kanban-aligned engagement model
- CTO Guide to Scaling Capacity -- Choosing the right methodology for your team size