Introduction
The world of Agile software development is ever evolving, with methodologies and frameworks constantly adapting to the complexities of modern business demands. In the new product development market, the most used frameworks are Scrum, the framework usually identified with Agile product development, and more recently, Kanban, a 60-year-old Lean practice adapted to knowledge work. While both are considered part of Lean and Agile thinking, their application, philosophy, and impact on teams can diverge significantly. This blog post explores the transition that teams face when moving from Scrum’s iterative sprint increments to the continuous flow model of Kanban. We’ll examine forum discussions and real-world experiences reflecting on this shift, highlight the potential pitfalls—especially how Kanban can become an Agile inhibitor—and offer recommendations for teams navigating this transition.
Challenges: The Shift from Scrum to Kanban
Losing the Heart of Agile: From Incremental Improvement to Standardisation
Scrum advocates for short, time-boxed sprints—typically two to four weeks—where teams aim to deliver a potentially shippable increment of product to end users. This cadence is interspersed with regular retrospectives, where teams reflect and commit to continuous improvement. The rhythm of inspect-and-adapt is at Scrum’s core.
Kanban, on the other hand, emphasises flow: work items move continuously through a value-stream-mapped process. By visualising work and limiting work-in-progress (WIP), Kanban aims to optimise throughput and reduce cycle times. However, when organisations transition from Scrum to Kanban, they often do so to remove the perceived challenge of Sprints, estimation, and ceremonies. Unknown to many Agile teams, kanban emerged from production lines where standardisation is the primary way of eliminating or reducing waste and achieving the six defects per one million opportunity quality standards. In the 1990s, the Agile Manufacturing philosophy proposed an alternative to Lean practices, like kanban, that were seen as inadequate for the 21st Century, where the market is characterised by frequent and significant changes, changes that can’t be managed by standardised practices.
Unfortunately, forum discussions reveal a recurring theme: teams adopting Kanban often stop practising retrospectives, cease incremental process tweaks, and instead focus on stabilising flow. This leads to a form of process standardisation—work becomes routine, and improvement plateaus. The very essence of Agile, which is rooted in relentless adaptation and learning, is suppressed. Kanban, in this light, becomes less an enabler of Agility and more a signpost that Agile has failed or stagnated.
Flow Obsession: The Trap of Local Optimisation
Another challenge raised in the Agile community of practice is the tendency for teams to become obsessed with optimising flow metrics—cycle time, throughput, and WIP limits. While these are valuable, the relentless drive for flow can mask underlying problems. Teams may unconsciously avoid challenging work, technical debt, or innovation in favour of predictable, smooth flow. Scrum’s sprint-based model, by contrast, makes it harder to ignore such issues due to built-in reflection points and shared objectives.
Kanban as an Agile Inhibitor
Ironically, Kanban—when poorly implemented—can inhibit Agility. Without the enforced cadence of Scrum’s Sprint Reviews and Retrospectives, teams lose structured opportunities for feedback and learning. Process improvement becomes reactive rather than proactive. In forums, Agile practitioners share stories of teams “doing Kanban” but failing to respond to change, evolve their processes, or innovate. The Kanban board becomes a visualisation tool for a static process, rather than a dynamic engine for change.
The Risk of Negating Scrum Values
Scrum is more than a scheduling tool; it embodies values such as focus, commitment, openness, respect, and courage. The sprint structure enforces prioritisation and shared goals. Transitioning to Kanban can dilute these values if not accompanied by deliberate process discipline. Teams may become fragmented, working on tasks in isolation, and lose the sense of collective ownership.
Recommendations: Navigating the Transition
Maintain the Spirit of Continuous Improvement
If your team is moving from Scrum to Kanban, don’t abandon retrospectives. Schedule regular cadence-based reviews, even if your work is now continuous. Maintain a backlog of process improvement items and review them with the same rigour as your product backlog.
Use Kanban to Expose, Not Conceal, Bottlenecks
Kanban should illuminate process pain points and inefficiencies—not mask them. Use flow metrics to identify improvement opportunities and combine them with qualitative feedback from the team and stakeholders. Don’t fall into the trap of optimising for flow at the expense of innovation and adaptability.
Guard Against Standardisation Complacency
Process standardisation can improve efficiency, but it should not become a substitute for agility. Use standardisation as a baseline, not a ceiling. Challenge your team to experiment with new practices, technologies, and ways of working. Celebrate learning, even when it disrupts flow in the short term.
Preserve Core Agile and Scrum Values
Even within a Kanban framework, reinforce the core values that made your Scrum team successful. Foster collaboration, shared ownership, and commitment to delivering value. Use collaborative planning sessions, reviews, and open communication to maintain team cohesion.
Blend Practices Thoughtfully
There is no one-size-fits-all approach. Many teams successfully blend Scrum and Lean practices, retaining the structure of Sprints while visualising flow and limiting WIP. Experiment with hybrid models that empower your team to remain both efficient and adaptable.
The Bottom Line
Transitioning from Scrum’s iterative sprints to a continuous, Kanban-based flow model is not inherently a sign of progress. When teams drop the discipline of continuous improvement and focus solely on flow, they risk losing the Agility that drove their success in the first place. Kanban can easily become an Agile inhibitor and a sign that the spirit of Agile has failed—especially if process standardisation triumphs over experimentation and learning. The key is to preserve the Agile focus on incremental, relentless improvement, regardless of the process model.
Questions for Readers
- Has your team transitioned from Scrum to Kanban? What challenges and lessons did you encounter?
- How do you ensure continuous improvement and feedback within a flow-based model?
- Do you think process standardisation is helpful or harmful to agility in your context? Why?
Share your experiences below and keep the dialogue going—your insights could help others navigate this complex transition.
