Part 3: Kanban and Other Agile Frameworks
Part of the Agile Development 101 Series
Beyond Scrum: My Journey with Kanban
After years of working with Scrum, I joined a team that practiced Kanban. My first reaction? "Where are the sprints? How do we know what to work on?" I felt lost without the familiar structure of sprint planning and reviews.
But over time, I discovered that Kanban offered something Scrum didn't: continuous flow. Instead of the stop-start rhythm of sprints, work flowed smoothly through our system. For certain types of work - especially operational tasks, support, and maintenance - Kanban proved superior.
In this article, I'll share my experiences with Kanban, compare it to Scrum, and introduce other agile frameworks I've encountered.
What is Kanban?
Kanban is a method for managing knowledge work with emphasis on just-in-time delivery and not overloading team members. The name comes from Japanese manufacturing (Toyota Production System) and means "visual signal" or "card."
Core Principles
Unlike Scrum with its defined roles and ceremonies, Kanban starts with what you're doing now and evolves incrementally.
The four foundational principles I follow:
Start with what you do now: Don't restructure everything
Agree to pursue incremental change: Small improvements over revolution
Respect current processes and roles: Kanban is evolutionary, not revolutionary
Encourage acts of leadership at all levels: Anyone can suggest improvements
The Six Core Practices
Visualize the workflow
Limit Work in Progress (WIP)
Manage flow
Make policies explicit
Implement feedback loops
Improve collaboratively
Let me explain each through my experience.
Visualizing the Workflow
The first thing I did was map our actual workflow:
Why this matters:
When work is invisible, it's hard to manage. By visualizing our workflow, we could see:
Where work piled up (bottlenecks)
What each person was working on
How long items stayed in each stage
My Kanban Board Setup
I use Jira or GitHub Projects with these columns:
Card details:
Title and description
Priority (High/Medium/Low)
Assignee
Age (days in current column)
Type (Feature/Bug/Tech Debt)
Limiting Work in Progress (WIP)
This was the hardest practice for me to adopt. I wanted to start new things, but WIP limits force discipline.
Why WIP Limits Matter
My experience without WIP limits:
Started 10 tasks, finished none
Context switching killed productivity
Everything was "in progress," nothing was done
Hidden bottlenecks
With WIP limits:
Finished 3 tasks completely in the same time
Bottlenecks became obvious
Team swarmed to finish rather than start
Higher quality (less context switching)
How I Set WIP Limits
I use this formula:
For a 5-person team:
Total WIP across all active columns: 6-7 items max
Per column limits based on typical distribution
Example:
What Happens When WIP is Reached
Scenario: Code Review column is full (2/2 limit)
Developers can:
Review someone else's code (help move work forward)
Work on technical debt
Write documentation
Help test
Developers cannot:
Move their completed work to Code Review
Start new development work
This forces the team to finish work, not just start it.
My WIP Limit Experiments
I've tried different approaches:
Strict limits: Hard stop when limit reached
Pros: Forces discipline
Cons: Can feel rigid
Soft limits: Warning when exceeded
Pros: More flexible
Cons: Limits often ignored
My preference: Strict limits with emergency override (requires team discussion)
Managing Flow
Flow is about getting work through the system smoothly and predictably.
Lead Time vs. Cycle Time
Two metrics I track:
Lead Time: Time from request to delivery
Cycle Time: Time from starting work to delivery
Example:
Cumulative Flow Diagram (CFD)
I use CFD to visualize flow over time:
The CFD shows:
How much work is in each stage
Whether WIP is growing or stable
Where bottlenecks occur
Healthy flow:
Steady bands (not growing)
Work moves smoothly through stages
Predictable delivery
Unhealthy flow:
Bands expanding (WIP growing)
Flat sections (nothing moving)
Erratic patterns (unpredictable)
Optimizing Flow
When I notice flow issues, I investigate:
Bottleneck in Code Review?
Pair program more (reviews during development)
Rotate reviewers
Set SLA for review time
Reduce PR size
Bottleneck in Testing?
Automate more tests
Developers test their own work first
Add QA capacity
Too much WIP in Progress?
Lower WIP limits
Encourage swarming on tasks
Break down large tasks
Making Policies Explicit
Hidden rules slow teams down. I make policies visible.
Examples from My Board
Definition of Ready (for starting work):
Definition of Done:
Priority Guidelines:
Pull Signals:
These policies are documented on our Confluence page and referenced by the team.
Implementing Feedback Loops
Kanban has fewer prescribed ceremonies than Scrum, but feedback is still critical.
My Kanban Meetings
Daily Standup (15 min)
Focus: Flow, not individuals
Questions:
Are there any blockers?
Is anything aging in a column too long?
Are we close to any WIP limits?
Can we help move work forward?
Example:
Replenishment Meeting (Weekly, 30 min)
Focus: Prepare upcoming work
Agenda:
Review backlog
Clarify top priorities
Ensure items are ready to pull
Estimate if needed
Similar to Scrum's backlog refinement, but focuses on next items to pull, not a whole sprint.
Service Delivery Review (Monthly, 1 hour)
Focus: Metrics and improvement
Agenda:
Review lead time and cycle time trends
Analyze flow (CFD)
Identify bottlenecks
Discuss improvement experiments
Example metrics review:
Retrospective (Monthly, 1 hour)
Focus: Team dynamics and process
Similar to Scrum retros, but often less frequent since Kanban changes incrementally.
Improve Collaboratively
Kanban encourages evolutionary change through experiments.
My Improvement Process
Identify problem: "Code reviews are slow"
Hypothesize solution: "Limiting PR size will speed reviews"
Define experiment: "PRs capped at 300 lines for 2 weeks"
Measure: "Track review time before/after"
Review and adapt: "Review time down 40%, make permanent"
A/B Testing Process Changes
I treat process changes like feature experiments:
Experiment Log:
Kanban vs. Scrum: A Comparison
Having used both extensively, here's my comparison:
Kanban Strengths
Better for:
Continuous flow work (support, operations)
Teams with unpredictable demand
Mature teams comfortable self-organizing
Work with varying sizes
Environments needing flexibility
Example: My DevOps team uses Kanban because:
Incidents arrive unpredictably
Work varies from 15-minute fixes to 3-day investigations
Can't commit to sprint goals with unknown interruptions
Scrum Strengths
Better for:
Product development with clear goals
Teams new to agile (more structure)
Predictable capacity planning
Regular stakeholder demos
Learning and bonding (ceremonies build culture)
Example: My product team uses Scrum because:
Clear feature roadmap
Stakeholders want regular demos
New team benefits from structure
Predictable release cycles
Hybrid Approach: Scrumban
I've successfully combined elements:
From Scrum:
Sprint planning (every 2 weeks)
Sprint reviews (demo completed work)
Retrospectives (continuous improvement)
From Kanban:
Continuous flow within sprint
WIP limits on board columns
Pull-based system
Metrics (lead time, cycle time)
Why it works:
Structure of sprints with flow of Kanban
Regular ceremonies for alignment
Flexibility for changing priorities
Example board:
Other Agile Frameworks
Beyond Scrum and Kanban, I've encountered other frameworks:
Extreme Programming (XP)
Focus: Technical excellence through practices like:
Pair programming
Test-driven development (TDD)
Continuous integration
Refactoring
Simple design
My experience:
I adopted several XP practices:
Pair programming: For complex features and knowledge transfer
TDD: Write tests first for core logic
CI/CD: Automated builds and deployments
Refactoring: Continuous code improvement
When it works:
Teams value technical quality
Business supports technical practices
Code complexity demands rigor
Tools: GitHub Actions for CI, Jest for TDD, VS Code Live Share for pairing
Lean Software Development
Focus: Eliminate waste, amplify learning, deliver fast
Seven principles:
Eliminate waste
Build quality in
Create knowledge
Defer commitment
Deliver fast
Respect people
Optimize the whole
My application:
I use Lean thinking to:
Identify waste (waiting, excess documentation, context switching)
Optimize value stream (minimize handoffs)
Empower team decisions
Focus on flow efficiency
Example:
Feature-Driven Development (FDD)
Focus: Delivering tangible, working features regularly
Five processes:
Develop overall model
Build feature list
Plan by feature
Design by feature
Build by feature
My experience:
Limited but useful for:
Large, complex domains
Feature-focused roadmaps
Client billing by feature
When it works:
Clear feature boundaries
Domain modeling is valuable
Regular feature delivery expected
Dynamic Systems Development Method (DSDM)
Focus: Business-driven, time-boxed delivery
Principles:
Focus on business need
Deliver on time
Collaborate
Never compromise quality
Build incrementally
My experience:
Rarely used in pure form, but principles guide my work:
Business value trumps technical elegance
Time-boxing prevents scope creep
Quality is non-negotiable
SAFe (Scaled Agile Framework)
Focus: Scaling agile to large enterprises
Levels:
Team level (Scrum/Kanban teams)
Program level (Agile Release Train)
Portfolio level (Strategic themes)
My experience:
I've worked in a SAFe environment at a large enterprise:
Pros:
Coordination across 50+ teams
Aligned roadmap
Regular synchronization (PI Planning)
Cons:
Heavy process overhead
Lost agile nimbleness
Ceremony fatigue
When it works:
Large organizations (100+ developers)
Complex dependencies
Regulatory requirements
Leadership buy-in
When it doesn't:
Small companies (overkill)
Fast-moving products (too slow)
Teams forced to adopt (resentment)
Choosing the Right Framework
Based on my experience, here's how I choose:
Use Scrum When:
✅ Team is new to agile
✅ Product has clear roadmap
✅ Stakeholders want regular demos
✅ Predictable capacity needed
✅ Team needs structure
Use Kanban When:
✅ Continuous flow work (support, ops)
✅ Unpredictable demand
✅ Mature, self-organizing team
✅ Varying work sizes
✅ Focus on flow optimization
Use Scrumban When:
✅ Need structure and flexibility
✅ Transitioning from Scrum to Kanban
✅ Product + operations work mix
✅ Team wants best of both
Use XP Practices When:
✅ Technical quality critical
✅ Complex codebase
✅ Pair programming feasible
✅ TDD culture exists
Use Lean When:
✅ Eliminating waste is priority
✅ Optimizing value stream
✅ Manufacturing-like processes
✅ Focus on flow efficiency
Use SAFe When:
✅ Large organization (100+ devs)
✅ Multiple dependent teams
✅ Regulatory compliance needs
✅ Executive support exists
My Framework Evolution
My journey through frameworks:
Year 1-2: Pure Scrum
Learned agile fundamentals
Appreciated structure and ceremonies
Built team cohesion
Year 3-4: Scrum with XP Practices
Added pair programming
Adopted TDD
Implemented CI/CD
Improved technical quality
Year 5-6: Scrumban
Introduced WIP limits
Added flow metrics
Kept sprint structure
Gained flexibility
Year 7+: Context-Dependent
Scrum for product teams
Kanban for ops teams
XP practices everywhere
Lean thinking throughout
Lesson learned: No framework is perfect. Adapt to your context.
Implementing Kanban: A Practical Guide
If you want to try Kanban, here's my step-by-step approach:
Step 1: Map Current Workflow
Ask:
What stages does work move through?
Who does what?
Where does work wait?
Example mapping session:
Step 2: Create Visual Board
Use Jira, GitHub Projects, or even a physical board:
Step 3: Start Without WIP Limits
Observe current flow:
How much WIP naturally exists?
Where does work pile up?
How long does work take?
Track for 2-4 weeks.
Step 4: Set Initial WIP Limits
Based on observations:
Start conservative, adjust based on data.
Step 5: Measure Metrics
Track:
Lead time
Cycle time
Throughput (items completed per week/month)
Blocked items
Use Jira's built-in reports or custom dashboards.
Step 6: Hold Regular Meetings
Start with:
Daily standup (15 min)
Weekly replenishment (30 min)
Monthly service delivery review (1 hour)
Step 7: Experiment and Improve
Try improvements:
Adjust WIP limits
Change column definitions
Add/remove stages
Improve policies
Measure impact, keep what works.
Common Kanban Mistakes
Things I've learned the hard way:
Mistake 1: No WIP Limits
Problem: Kanban becomes a glorified to-do list Solution: Set and enforce WIP limits
Mistake 2: Ignoring Flow Metrics
Problem: Can't measure improvement Solution: Track lead time, cycle time, throughput
Mistake 3: Too Many Columns
Problem: Complex board, hard to manage Solution: Keep 5-7 columns maximum
Mistake 4: No Prioritization
Problem: Work on whatever feels interesting Solution: Explicit priority system (use backlog ordering)
Mistake 5: No Explicit Policies
Problem: Team unclear on when to pull work Solution: Document and share policies
Conclusion
Kanban offers a powerful alternative or complement to Scrum. Key lessons:
Kanban core:
Visualize workflow
Limit WIP
Manage flow
Explicit policies
Feedback loops
Continuous improvement
When to use:
Continuous flow work
Unpredictable demand
Mature teams
Optimization focus
How to start:
Map current flow
Create visual board
Measure baseline
Set WIP limits
Experiment and adapt
In the next article, we'll explore the tools that make agile work - Jira, GitHub, Confluence, and more - and how to set them up effectively.
Key Takeaways
Kanban emphasizes flow over iterations
WIP limits are critical - finish work, don't just start it
Measure lead time and cycle time to understand performance
Start with current process, improve incrementally
Different contexts need different frameworks - choose wisely
Scrumban combines structure and flow effectively
No framework is perfect - adapt to your needs
Additional Resources
"Kanban: Successful Evolutionary Change for Your Technology Business" by David J. Anderson
"Personal Kanban" by Jim Benson and Tonianne DeMaria Barry
KanbanFlow - Simple Kanban tool
LeanKit - Enterprise Kanban platform
Previous: Part 2 - Scrum Framework Next: Part 4 - Agile Tools and Workflows
This article is part of the Agile Development 101 series. Check out the series overview for more content.
Last updated