In the article below our authors Jon & Steve will give an explanation about both Kanban and Scrum topics as well as Kanban vs Scrum comparation.

Doing the work.

We are not a person to treat the approach to work as dogmatic. Context matters and the work environment’s various parameters will influence the best approach. For example, these parameters include industry, staffing levels, competency, associated risks, and too many more to list. To this end, it is best to have some essential tools in our metaphorical backpack and select the appropriate approach given the circumstances.

What is Kanban?

Kanban is a method for managing and improving workflows. It was initially developed in the 1950s by Toyota and is now used in various industries and organizations worldwide.

The term "Kanban" means "signboard" or "billboard" in Japanese, and it refers to the visual signals that are used to trigger action in the workflow. In a Kanban system, work is represented by cards or other visual elements that move through a series of steps or stages.

Each step represents a different stage in the workflow. Colored cards (see below) that represent each work item are created. These cards will be moved through the approved work stages as work is accomplished. The card movement is controlled by work rules that are agreed upon by the team as the work item progresses.

One of the critical principles of Kanban is that work should only be started when needed and that work should only be done at a rate that can be sustained over time. The undertaking of a task is not based upon the desire to conclude the work at a particular date.

This helps avoid overloading the team with too much work and allows team members to focus on the most critical tasks. Unfortunately, from experience, this overloading is a significant source of project failures.

Kanban can be used in various contexts, including software development, manufacturing, and project management. In addition, it is often used in conjunction with other agile methodologies, such as Scrum, to provide a more flexible and responsive approach to work.

When is Kanban used?

Kanban is often used in manufacturing, software development, and other project management contexts where there is a need for continuous improvement and the ability to adapt to changing customer needs and priorities. It is also used in service industries such as hospitals, retail, and finance. Kanban can be used in any industry or organization with a workflow process involving the movement of physical or digital products or tasks through various stages of production or completion.

Steps in Kanban

There are but a few steps in the process and the simplicity makes it a desirable approach when the work itself can be complex.

  1.  Identify the work to be done: This involves defining the project's scope and breaking it down into smaller tasks or items. These work items are put on individual cards.
  2. Create a visual representation of the work: This involves creating a Kanban board, which is a visual representation of the work that needs to be done, the work that is currently in progress, and the work that has been completed.
  3.  Establish workflow: This involves defining the process for how work will move through the Kanban board, including the stages it will go through (such as "to do," "in progress," and "done") and the rules for how work will be moved between these stages.
  4. Set limits on work in progress: This involves establishing limits on the number of tasks or items that can be in progress at any given time to ensure that work is prioritized and that team members are not overwhelmed with too much work.
  5. Monitor and adjust the process: This involves regularly reviewing the Kanban board and making adjustments as needed to optimize the workflow and ensure that work is being completed efficiently and effectively.

When is Kanban not to be used?

There are a few instances where Kanban may not be the best method to use:

  1. When the workflow is not clearly defined: Kanban relies on the precise definition of a workflow, so if the steps involved in a process are not well-defined or are constantly changing, it may not be the most effective method.
  2. When the team is not committed to continuous improvement: Kanban requires the team to review and optimize the workflow regularly, so if the team is not committed to this process, it may not work as well.
  3. When the team is working on one-off projects: Kanban is designed for ongoing workflows, so it may not be the best fit for a team working on a single, one-off project.
  4. When the team is not co-located: Kanban relies on team members being able to see and communicate with each other easily, so it may not work as well for remote teams or teams that are not co-located.


Agile project management is a set of principles for software development that emphasizes flexibility, rapid iteration, and collaboration between teams. It was developed in response to traditional, Waterfall-style project management, which can be inflexible and slow to respond to change.
In Agile project management, teams work in short cycles called "sprints" to quickly deliver high-quality software. Sprints usually last two to four weeks, during which teams complete a defined set of tasks and review their progress with stakeholders. This allows teams to quickly adapt to changing requirements and deliver value to their customers on a regular basis.
Agile project management is centered around the Agile Manifesto, a set of values and guiding principles for Agile development. The manifesto emphasizes individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.
Agile project management methods include Scrum, Extreme Programming (XP), and Lean Development. These methods all share the same basic principles but have slightly different approaches and tools.

What is Scrum?

Scrum is a framework for managing and completing complex projects. It is commonly used in software development but can also be applied to other fields. It is based on the principles of transparency, inspection, and adaptation. In a Scrum project, a team works together to complete a set of deliverables (called a "sprint") in a fixed amount of time. The team meets regularly to review progress, identify obstacles, and adapt their work as needed. Scrum's goal is to deliver customer value as quickly and efficiently as possible.

  1. Planning: The team gathers to discuss the project goals, scope, and user stories. They also identify any potential obstacles or risks and create a plan for addressing them.
  2. Development: The team works on completing user stories and delivering them to the product owner for review. They may also conduct daily stand-up meetings to check in with each other and discuss progress.
  3. Review: The product owner reviews the completed user stories and provides feedback. The team may also conduct a demo of their work for the product owner and stakeholders.
  4. Retrospective: The team reflects on their work from the previous sprint and discusses what went well and what could be improved. They may also identify any actions to take to improve their process in the next sprint.
  5. Repeat: The process starts again with the planning phase for the next sprint.

When is Scrum used?

Scrum is typically used in agile software development projects where there is a need for frequent adjustments to the project plan and a high level of collaboration among team members. It is also often used in other types of projects where there is a need for flexibility and adaptability to changing circumstances or requirements.

When is Scrum not to be used?

There are several situations in which Scrum may not be the best choice for a project or team:

  1. If the team (or the organization) is unwilling to commit to Scrum's principles and values, it will likely be difficult to implement and succeed with the framework.
  2. If the project is not well-defined and there is little clarity on what needs to be done, Scrum may not be suitable as it relies on well-defined goals and deliverables.
  3. If the team is not able to commit to frequent and regular meetings, such as daily stand-ups and sprint planning sessions, Scrum may not be practical.
  4. If the team is not comfortable with transparency and open communication, the principles of Scrum may be difficult to adopt.
  5. If the project requires a rigid, inflexible plan, Scrum may not be suitable as it is designed to be agile and adaptable.

Compare Scrum and Kanban

Scrum and Kanban are two different project management frameworks that are commonly used in software development. Here are some key differences between the two:

  1. Philosophy: Scrum is based on the Agile philosophy, which emphasizes iterative and incremental development, flexibility, and continuous improvement. Kanban, on the other hand, is based on the Lean philosophy, which emphasizes continuous flow, value, and waste reduction.
  2. Roles: Scrum has three defined roles: the Product Owner, the Scrum Master, and the Development Team. Kanban does not have any defined roles, but rather focuses on the work being done and the team's process for completing it.
  3. Meetings: Scrum has several defined meetings, including the daily stand-up, the sprint planning meeting, the sprint review, and the sprint retrospective. Kanban does not have any defined meetings, but rather relies on team members to communicate with each other as needed.
  4. Planning: In Scrum, the team plans out the work for a specific time frame called a sprint, and the scope of the work is fixed. In Kanban, the team plans work as it comes in and the scope is flexible.
  5. Work in progress limits: Scrum does not have any defined work in progress limits, but rather focuses on completing work in each sprint. Kanban emphasizes limiting the amount of work in progress in order to increase flow and reduce waste.

Overall, Scrum and Kanban are both effective project management frameworks, but they approach project management in different ways. Scrum is more suited for teams that need to plan and prioritize work in advance, while Kanban is better for teams that need to be more flexible and responsive to changing demands.

Contrast scrum and Kanban

Scrum and Kanban are two different project management methodologies that have been developed to help teams deliver products and services more effectively. While both methodologies have similar goals, they have some key differences that set them apart.
Scrum is a framework for managing complex projects focused on short bursts of work called "sprints." In Scrum, a team works together to complete a set of goals within a fixed time frame, usually two to four weeks. The team meets regularly to review progress and make adjustments as needed.

Scrum focuses on rapid delivery, collaboration, and continuous improvement.

On the other hand, Kanban is a pull-based system for managing workflows. It is designed to help teams visualize and optimize their workflow by breaking tasks into smaller pieces and organizing them on a board.

The board is divided into columns, each representing a different stage in the workflow. When a task is completed, it is moved to the next column. The goal of Kanban is to optimize work flow and reduce waste.

One key difference between Scrum and Kanban is the way they approach planning and scheduling. In Scrum, the team plans and schedules work in advance during sprint planning meetings. In Kanban, work is planned and scheduled on an as-needed basis, with a focus on flexibility and adapting to changing needs.

Another difference is that Scrum has defined roles and responsibilities, with the Scrum Master responsible for facilitating the process and the Product Owner is responsible for determining the goals and business priorities for the team. Kanban does not have these defined roles, and team members can take on any tasks as needed.


Scrum and Kanban are valuable tools for managing complex projects and improving team productivity. The choice between the two depends on the team's needs and goals, the project's specific requirements, and the organization's culture. Dogma does not help resolve our work difficulties, heuristics as guidelines do, and adapting accordingly to the organization and circumstances.