XP + Kanban

XP originally used iterations—one or two weeks of planned work, then a demo and planning session. Kanban uses continuous flow: work items move through the system one at a time, without fixed batches.

These aren't incompatible. XP's core practices work with any flow system.

What changes:

• No iteration planning (you plan just-in-time)
• No iteration demos (you demo as features complete)
• No velocity in the Scrum sense (you measure lead time and throughput)

What stays the same:

• TDD (still write tests first)
• Pair programming (still collaborate on code)
• Refactoring (still keep design clean)
• CI (still integrate continuously)
• Small releases (Kanban encourages this even more)
• Customer involvement (still need someone to prioritize and accept)

The technical practices are independent of how you organize work.

Kanban's signature practice is WIP limits: constraining how much work is in progress at once.

This aligns with XP principles:

Focus: WIP limits prevent context switching. XP values focus (sustainable pace, pairing for deep work).

Flow: Limiting WIP creates flow. XP's small releases and CI also create flow.

Quality: Less WIP means less rushing. XP's quality focus benefits from reduced pressure.

Finish what you start: Both Kanban and XP favor finishing over starting. Don't start new work when existing work can be completed.

Pairing and WIP: If you pair program, WIP is naturally limited. Two people on one item means fewer items in flight.

The synergy is strong. Kanban's constraints complement XP's focus on quality and finishing.

Kanban pushes toward continuous delivery: every completed item is potentially releasable. XP's practices make this possible.

Why XP enables continuous delivery:

• Tests: Every feature is verified automatically
• CI: Code is always integrated and buildable
• Simple design: No complex release coordination
• Refactoring: Code stays clean and deployable
• Small releases: Already a core XP practice

Kanban without XP practices struggles to achieve continuous delivery. Without tests, you can't be confident things work. Without CI, integration is uncertain. Without simple design, releases are complex.

Together: Kanban says "deliver continuously." XP says "here's how."

ScrumBan combines Scrum, Kanban, and (often implicitly) XP:

From Scrum:

• Regular planning rhythms (though not necessarily sprint-locked)
• Retrospectives for improvement
• Product Owner role for prioritization

From Kanban:

• Visual board with WIP limits
• Flow metrics (lead time, throughput)
• Pull-based work (take next item when ready)

From XP:

• Engineering practices (TDD, pairing, etc.)
• Quality focus
• Sustainable pace

This hybrid works well for teams that want structure (Scrum) with flow (Kanban) and quality (XP).

The label matters less than the practices. Use what works; drop what doesn't.

When to use XP with iterations (Scrum-style):

• Stakeholders want predictable planning increments
• The team benefits from regular rhythm and reflection
• Work naturally batches into deliverables
• The organization thinks in sprints

When to use XP with flow (Kanban-style):

• Work arrives unpredictably (support, operations)
• Continuous deployment is the goal
• Iteration boundaries feel artificial
• The team is mature enough to self-manage without imposed rhythm

Either approach works with XP practices. The practices remain; the organizational wrapper changes.

Many teams evolve from Scrum toward Kanban as they mature. Iterations provide training wheels. Flow is the graduate level. But there's nothing wrong with staying with iterations if they work for you.