Agile Mindset

Agile, Scrum, Kanban, Gantt: In project meetings these four words often get used in the same breath, as if they were four options on one menu. They aren’t. One is a mindset, two are ways of working, and one is a chart. Once you see which is which, it becomes much easier to understand how they fit together, and why some combinations work better than others.

In short: Agile is the why, Scrum and Kanban are the how, and a Gantt chart is a way of drawing the when.

• Agile is the umbrella. It’s the 2001 Agile Manifesto: Four values (e.g. responding to change over following a plan) and twelve principles. It doesn’t prescribe how to work, only what to prioritize. Scrum and Kanban are older than the Manifesto, but they share its values. Scrum’s creators even helped write it. Today both are seen as ways to put Agile into practice.
• Scrum is the most prescriptive. Work happens in fixed-length sprints (usually 1–4 weeks), with three roles (Product Owner, Scrum Master, Developers), set events (planning, daily scrum, review, retrospective) and artifacts (product backlog, sprint backlog, increment). It’s an implementation of Agile.

• Kanban comes from a different place. It started in Toyota’s Lean manufacturing in the 1940s–50s and was adapted to software and knowledge work by David J. Anderson in the mid-2000s. Work flows continuously across a board, and work-in-progress (WIP) limits prevent overload. There are no sprints or mandatory roles. It fits under Agile in practice, but its roots are Lean.
• Gantt Chart is the odd one out. It’s not a methodology at all. It’s a bar-chart timeline that Henry Gantt popularized in the 1910s, showing tasks, durations and dependencies. It belongs to plan-driven (waterfall) management, where the full schedule is fixed up front. That’s somewhat at odds with Agile’s “respond to change.” Still, hybrid organizations often use Gantt-style roadmaps for high-level release planning while teams run Scrum or Kanban underneath.

How they overlap

• Scrum and Kanban aren’t rivals. Many Scrum teams use a Kanban-style board, and the blend is called Scrumban.
• The visual board is a shared tool that often gets mistaken for Kanban itself.
• The real dividing line is between adaptive work (Agile, Scrum, Kanban) and predictive work (Gantt, waterfall).

Kanban vs Gantt

Kanban and Gantt are often compared because both make work visible, just in very different ways. A Kanban board shows where each task stands right now. A Gantt chart shows when each task is supposed to happen. The table sums up how that difference plays out in practice.

In short, Kanban is built for work that changes often and arrives unpredictably, while Gantt is built for projects with a fixed scope, firm deadlines and many dependencies. The two can work together: many teams keep a Gantt-style roadmap for the big milestones and use a Kanban board for the day-to-day work.

Production Kanban vs Software Kanban

Where Kanban comes from: Kanban started on the factory floor. At Toyota, a card traveled with every container of parts. When the container was empty, the card went back upstream as the signal to make or deliver more, and only then. Because the number of cards was fixed, so was the maximum amount of stock in the system. This “pull” principle is still used in production and warehouses today, often as simple two-bin systems or electronic signals in ERP software. Software teams adopted the idea in the mid-2000s: the board replaced the cards, and WIP (Work in Progress) limits replaced the fixed card count.

How does it work and connect?

How production Kanban works: At Toyota in the late 1940s and 1950s, Taiichi Ohno built Kanban as part of the Toyota Production System and its just-in-time idea. He was reportedly inspired by American supermarkets, where shelves get restocked only when customers take goods off them.

The core is a pull system. Nothing gets produced or delivered until the next step signals that it needs it.

• The card (“kanban” is Japanese for signboard or card): each container of parts carries a card. When a station uses up a container, the card goes back upstream as a signal: make or deliver exactly this amount again.
• Two main card types: a withdrawal (or conveyance) kanban authorizes moving parts from one station to the next. A production kanban authorizes making new ones.
• The number of cards caps the inventory. If there are five cards in circulation, there can never be more than five containers in the system. That’s the direct ancestor of the WIP limit.

• Two-bin system: the simplest warehouse form. Parts sit in two bins. When the first is empty, it triggers a reorder, and you work from the second until the refill arrives.
• E-kanban: today the cards are often barcodes or signals in an ERP or warehouse system, but the logic is the same.

The goal is to avoid overproduction and excess stock, which Lean counts among the biggest forms of waste.

How it connects to software Kanban: Around the mid-2000s, David J. Anderson carried the principles over to knowledge work, not the physical mechanics:

Production / warehouse	Knowledge work
Physical card or bin	Card on a board
Card returns = pull signal	Free slot in a column = pull signal
Number of cards caps inventory	WIP limit caps work in progress
Goal: no excess stock	Goal: no overload, faster flow

In production, Kanban is a tool for controlling material flow. In software, it’s a method for managing work. Same name and same pull logic, different setting. Neither has anything to do with the Agile Manifesto, since production Kanban came half a century earlier.

The 4 Agile Values

Each value names two good things and says which one takes priority when they compete:

• Individuals and interactions over processes and tools. Good people talking directly solve problems faster than any workflow or software. Tools should support collaboration, not replace it.
• Working software over comprehensive documentation. Progress is measured by something that actually works, not by specs and reports. Documentation is fine when it serves a purpose.
• Customer collaboration over contract negotiation. Instead of locking requirements into a contract and arguing about them later, work with the customer continuously to discover what they really need.
• Responding to change over following a plan. Plans are useful, but requirements, markets and understanding shift. Adapting is worth more than sticking to an outdated plan. This is the value that sets Agile most clearly apart from Gantt-style planning.

The 12 Agile Principles

Principles paraphrased; the original text is at agilemanifesto.org

Delivering value

1. The top priority is satisfying the customer by delivering valuable software early and continuously.
2. Welcome changing requirements, even late in development, because adapting gives the customer a competitive edge.
3. Deliver working software frequently, every few weeks to a couple of months, and prefer the shorter cycle.
4. Working software is the main measure of progress.

People and collaboration

5. Businesspeople and developers should work together daily throughout the project.
6. Build projects around motivated people. Give them the environment and support they need, and trust them to get the job done.
7. Face-to-face conversation is the most effective way to share information within a team.
8. The best architectures, requirements and designs come from self-organizing teams.

Sustainability and quality

9. Work at a sustainable pace. Sponsors, developers and users should be able to keep it up indefinitely, so no permanent crunch.
10. Continuous attention to technical excellence and good design makes the team more agile.
11. Simplicity, meaning the art of maximizing the work not done, is essential.

Improvement

12. At regular intervals, the team reflects on how to become more effective, then adjusts its behavior.

How Agile connects to Scrum and Kanban

• Gantt-style planning fits awkwardly with value 4 and principle 2, because it assumes the plan is known up front.

Conclusion

Agile, Scrum, Kanban and Gantt don’t compete. They work at different levels. Agile sets the priorities: People, working results, collaboration and adapting to change. Scrum and Kanban are two proven ways to live those priorities day to day, one through fixed rhythms, the other through continuous flow. The Gantt chart comes from a different tradition, where the plan is fixed up front. That’s why it mostly shows up in Agile settings as a high-level roadmap, not as the team’s daily tool.

What’s More

My Blog

My Interests

My Quotes