Scrum Agile Project Management

If You Are Done Scrumming, Try Some Kanban!

Even if Scrum is the most popular Agile framework used in software development, it is not the only approach you can use. In this article, Mark Haynes discusses why you might consider Lean Kanban as a better approach for your organization.

Author: Mark Haynes,

What both Lean Kanban and Scrum have in common is that they are philosophy, not a methodology. The concept of a framework is an important distinction since it permits flexibility in its implementation. Scrum teams can be prone to less than optimal behaviors that Lean Kanban can help to re-adjust. Let’s think about what a few of these might be.

  1. Monster User Stories eating your Scrum board
  2. Teams fixated on ceremonies and not on process efficiencies
  3. Release dates dominate the Sprint, turning Cadences into a schedule
  4. The Retrospective becomes an ineffective change feedback loop

Using Kanban instead of Scrum in Agile Software Development

What are the advantages for a team to go Lean Kanban? I think there are quite a few. After doing Scrum for a few years teams sometimes lose their way and become comfortable with less than optimal behaviors. You can address these using Scrum but do you need to change your framework to fix these problems? Notice these are all queuing problems and are often a question of the team’s behavior. Those are much harder to address using Scrum. Does a Lean Kanban philosophy offer advantages? Let’s explore what it means to be Lean Kanban.

Lean Kanban

Lean Kanban is not Scrum. They are complementary, but not compatible. One of the foundational principles of both Scrum and Lean Kanban is the Deming Improvement Cycle or PDSA (Plan-Do-Study-Act). Lean Kanban originates from the Toyota Production System. Which, in turn, was adopted from the Manufacturing techniques of Henry Ford and the Statistical Quality Control ideas of Edwards Deming

Kanban is based on Just-In-Time and Lean manufacturing concepts. It is all about the efficient flow of work through a queue. The unit of work is a work package, which isn’t predefined like a User Story. The focus is on managing work as it flows through a queue and reducing waste. By definition, Kanban is not methodology-specific. Unlike Scrum, it is not based on defined ceremonies and a fixed-length schedule called a Sprint.

Kanban is not a scheduling system but rather a visualization of the workflow, which pulls work from one aspect of the queue to another, a process implemented in Kanban boards. It is a Pull system, not a Push system. A Push system pushes work forward after a task is completed, as most project management schedules employ. A Pull system on the other hand uses a trigger to indicate that work can be “Pulled” to the next step.

When considering Lean Kanban, it is necessary to include Kaizen as well. The Kaizen method is a philosophy of continuous incremental improvements. The foundations of the Kaizen method consists of five founding elements:

  1. Teamwork
  2. Personal discipline
  3. Improved morale
  4. Quality circles
  5. Suggestions for improvement

Finally, we need to discuss the seven wastes of Lean Manufacturing or “Muda” as defined by Toyota. This can be defined as any activity that does not add value to a customer.

  1. Motion – Movements (machine or employee) that are more complicated than necessary.
  2. Inventory – Inventory that doesn’t directly fulfill customer needs is excessive and should be reduced to a level that directly supports the value stream.
  3. Waiting – Any idle time caused by the asynchrony of two or more interdependent processes.
  4. Defects – Includes quality errors that necessitate reworking, replacement, and customer dissatisfaction.
  5. Overproduction – When production exceeds customer requirements, which leads to high levels of inventory, which hides many organizational problems.
  6. Transportation – Waste of movement of materials that don’t directly correspond to some value-adding process.
  7. Over-processing – This is the waste of putting more work into producing the product than the customer values.

Foundational Principle of Kanban

  • Start with what you do now
  • Agree to pursue evolutionary change
  • Initially, respect current roles, responsibilities & job titles
  • Encourage acts of leadership at all levels

You could very well argue that all of this can be done with Scrum and this is true. Scrum teams can incorporate much of what is known as Lean Kanban. The Kanban approach after all encourages you to start with what you know.

Maybe your team just needs to be more Scrum-like or maybe they need a new attitude? Now let’s consider the core practices which are needed to satisfy those principles.

Using Kanban instead of Scrum in Agile Software Development

Core Practices of Lean Kanban

  • Visualized – Kanban only requires that work can be easily visualized, not that any specific workflow is used.
  • Limit Work In Progress (WIP) – To work more efficiently through the pipeline, WIP is limited to reduce waste and inefficiencies. Work is never pushed forward, which creates bottlenecks but is pulled from one stage to another.
  • Manage flow – Monitor the queues, blockages, and dependencies and ensure there are visual controls that indicate issues.
  • Make policies explicit.
  • Implement feedback loops.
  • Improve collaboratively, evolve experimentally (using models and the scientific method)

Using Kanban instead of Scrum in Agile Software Development

Kanban Ceremonies

  • Kanban Meeting (Daily Stand-up) – Focus on the day ahead and immediate future. Specifically on attention to stalled work items.
  • Replenishment Meeting (weekly) – Selects tasks for the backlog.
  • Service Delivery Review (bi-weekly) – Determines how well the client is being served by the team’s output.
  • Risk Review (monthly) – Examines factors that put work delivery at risk.
  • Operations Review (monthly) – Manages different groups to determine ways to improve efficiencies of the whole.
  • Strategy Review (quarterly) – Evaluates the big picture: the market landscape, technology changes, strategic goals, and the direction of the Kanban road map.

What Do you have to lose?

Some teams have a hard time embracing Scrum and are inclined to embrace a continuous flow of work. There is already a lot of cross-over between Scrum and Lean Kanban. Scrum boards often morph into Kanban boards. Your ALM tools most likely enforce the use of a Kanban board. User stories are Kanban messages. A sound practice of User Story development is to create small, independent, shippable units of work. Scrum Masters already worry about excessive inventory build-up in their Sprints. Why not just go all the way and become Lean Kanban. It’s all about the Flow baby!


KainNexus blog

The Kanban Method, The Kanban University,, David J Anderson


The Rhythm of Success: Kanban Meetings, Sonya Siderova, Nave

The Seven Wastes in Manufacturing, David McBride,

About the Author

Mark Haynes is a renaissance man trapped in a specialist’s body. Lately, he has been working as a Scrum Master and Agile Coach. Agile is a philosophy, not a methodology. In interviews, people often ask him how long you have been agile? His answer is “Always. I just didn’t know what it was called before.”