Browse Talent
Businesses
    • Why Terminal
    • Hire Developers in Canada
    • Hire Developers in LatAm
    • Hire Developers in Europe
    • Success Stories
  • Hiring Plans
Engineers Browse Talent
Go back to Resources

Engineering leadership | Blog Post

Agile vs Kanban: A Detailed Comparison

Wes Mitchell-Lewis

Share this post

The word Kanban makes me think of Cancan. It brings to mind an image of dancers in colorful costumes, side-by-side in a chorus line, arms over the shoulders of dancers to their left and right, every move synchronized and legs as high as they can reach. This image, coincidentally, is also a great analogy for Kanban.

The parallels between a chorus line and Kanban, a tool used to manage workflow, are in the visual display, coordination of movement, collaboration among team members, and the reach for excellence. 

There are no such parallels with Agile, because the Agile framework is conceptual, without tangible qualities. Whereas Agile is a vision, Kanban is a choreography. Learn more about the differences between Agile vs. Kanban below.

The Fundamentals of Agile

Agile is a methodology for thinking about project management rather than a tool for managing work efficiently, as is Kanban.

The Agile framework was developed in 2001 as an alternative to the Waterfall framework, a traditional methodology for project management. It was created specifically to meet the needs of the software development industry. 

The reality was that it was taking too long to develop software under traditional project management structures. It took an average of three years from the request for a software solution to the point of delivery. This was when the market was changing so rapidly, with the ever-increasing use of PCs in the 1990s, that products were often obsolete by the time they went to market. 

In the early 2000s, 17 leaders from the software development industry developed an alternative methodology. They began with the premise that the problems they faced were complex, the solutions were not known, and requirements would likely change in the process of development. 

This was anathema to the way of thinking under traditional project management. Waterfall, for example, sets the scope of the project at the onset. It then proceeds through a series of defined stages to the point of delivering the product agreed to from the start. At every stage of the project, one functional team comes in, does its work, and hands-off to the next team. There is little collaboration among functional teams and no collaboration with clients and stakeholders during the process of development.

In its search for a new model, the group of 17 – who came to be known as the Agile Alliance – had examples to build on. One was the project management tool called Scrum, developed about a decade earlier. Its founders, Ken Schwaber and Jeff Sutherland, named their tool after a term used in rugby, which means working together towards a common goal (Agile vs. Scrum). Compared with Waterfall’s siloed approach, this was a very different concept.

Schwaber and Sutherland were among the members of the Agile Alliance. The group held its most seminal meeting in Utah in 2001. That meeting culminated in the Manifesto for Agile Software Development, the origins of the Agile framework. 

The manifesto began with four values, which were presented in such a way as to emphasize how different Agile practices (described on the left) would be from Waterfall’s (implied on the right):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

These values were expanded on in the articulation of 12 principles. Compared to Waterfall, the differences in Agile’s approach to project management crossed every aspect, from scope, to process, to the composition of teams, to client interaction, to product delivery. 

By 2009, more software development organizations were using Agile than Waterfall.

The Fundamentals of Kanban

The origins of Kanban vs Agile are just as interesting. They date back to the 1940s in a Toyota manufacturing plant, where Kanban’s founder, Taiichi Ohno, worked as an industrial engineer. To compete with American car makers, he was motivated to control and manage work and inventory.

For inventory control, he borrowed from a system used in supermarkets. In very basic terms, the system worked like this: toward the back of every row of product was one item with a card attached. The card was a visual cue to stockers that it was time to order inventory. The shelf-stockers posted the card on a bulletin board. Someone in the purchasing department pulled the card from the board and ordered the product. 

This proved to be a very efficient way to manage inventory and reduce waste. Thus began the notion of just-in-time manufacturing processes, which spread through the automotive industry and beyond. 

In the software development industry, David J. Anderson is the authority on the use of Kanban. An author and management consultant with a background in electronic and computer science, he developed a “pull” system for a Microsoft group in 2004 and realized that it worked like a virtual Kanban.

A pull system is best described by what it’s not. Traditional project management uses a “push” system. Team members push work onto the next person when their tasks are done, regardless of the next person’s capacity to handle the work. This is what happens when teams work in silos, and it can lead to bottlenecks that are not easily seen or anticipated.

In a pull system, conversely, team members decide in unison when to do the hand-over, understanding that the next one up will only “pull” the work when he or she has the capacity to complete it. 

Over the next several years, Anderson and his colleagues added best practices to the pull system to form what is now called the Kanban method

Kanban’s Six Practices:

  1. Visualize workflow – This is the most important task and it’s done through the use of a Kanban board with columns to represent steps – e.g., To Do, In Progress, Complete – and cards to represent work items.
  2. Limit work in progress – Only have as many work items in progress as you have people to do the work. This will help the team prioritize tasks and focus on what has to get done. It will also reduce the need for multitasking, which is often not conducive to working efficiently. 
  3. Manage flow – Observe and analyze flow for any duplication, risks, and bottlenecks. Always strive for greater efficiency.
  4. Make process policies explicit – Define, document, and communicate processes for everyone on the team. If team members are aware of the processes, they are more apt to follow them and might see room for improvement. 
  5. Use feedback loops – Regular meetings with fixed times are necessary for essential feedback to and from the team. The frequency and length of meetings depend on their purpose. For example, meetings for planning long-term strategy will be longer in duration but less frequent than team meetings. 
  6. Improve collaboratively – Kanban aims to manage the flow of work to achieve continuous improvement and to do so without overburdening the team. Most Kanban systems measure productivity and provide data to help with this goal.

Understanding Agile vs Kanban

The discussion of Agile vs. Kanban is a nuanced one. For all of its virtues, Kanban is not a method for managing software development projects per se. It doesn’t advise on how to develop software, or on how to plan and implement projects specific to any one industry. Its main purpose is to continually improve workflow through the practices advanced by Anderson and his colleagues.

This is not to say that Kanban is not a useful tool for software development project managers. In this industry, the tool is most effective when used in combination with project management tools that align with the Agile framework, such as Scrum


Continue to explore the rest of Terminal’s content offerings. If you are interested in learning more about how Terminal can support your organization and accomplish your development goals, please get in touch with our team!

Recommended reading

Engineering leadership | Blog Post

Engineering Resilience: Build Strong Development Teams to Do More With Less