1 Overview
Agile is a set of values before it is a set of rituals. The values are simple to state and difficult to live: 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. Those values do not prescribe a particular meeting schedule, role structure, or artifact. They describe a stance toward software delivery that favors learning, feedback, and adaptation. Scrum and Kanban are two popular ways to put those values into practice, but they are not the same thing as Agile, and neither is a complete definition of it.
Because Agile is values-first, teams can adopt it without adopting Scrum or Kanban. A team might use a continuous flow of small changes, a weekly planning conversation, and a retrospective every few weeks. Another team might use fixed-length iterations with a product owner and a Scrum master. Both can be Agile if they honor the values. The risk is that teams treat the rituals as the goal. When that happens, the meetings continue but the values fade. The board fills with tickets, the standup becomes a status report, and the retrospective becomes a complaint session. The method is present, but the mindset is not.
This article compares Agile, Scrum, and Kanban on one board. It describes what each method is for, how a cycle runs, who does what, which artifacts matter, and where each approach struggles. The aim is honest comparison, not a sales pitch. No single method is best for every context. The useful question is which set of constraints helps this team deliver valuable software with less waste and more learning.
2 The problem this method was built to solve
Agile emerged from a frustration with heavyweight, plan-driven software development. In that world, requirements were gathered up front, designs were approved, and code was written to a specification that changed slowly if at all. Delivery happened late, feedback arrived later, and the cost of change was high. Teams often discovered that they had built the wrong thing only after months of work. The problem was not that planning was bad. The problem was that planning was treated as a one-time event rather than an ongoing conversation. Agile was built to shorten the distance between an idea and the learning that comes from putting working software in front of users.
Scrum was built to solve a related problem: how to organize complex product work when the requirements are uncertain and the team needs a steady rhythm. It adds structure to Agile values through fixed-length sprints, defined roles, and a small set of artifacts. The sprint creates a container for focus, and the review and retrospective create regular opportunities to inspect and adapt. Scrum is not a silver bullet, but it addresses the problem of teams that drift without a cadence or that lack clarity about who decides what.
Kanban was built to solve the problem of flow. It originated in manufacturing and was adapted to knowledge work, including software delivery. Its core insight is that too much work in progress slows everything down. By making work visible on a board and limiting how much can be in each stage, Kanban helps teams finish work rather than start more. It also exposes bottlenecks and policies that were previously implicit. Kanban is less prescriptive than Scrum about roles and ceremonies, which makes it flexible but also easier to do poorly.
3 How one cycle runs, from ready to done
In Agile, a cycle is any short loop that produces working software and generates feedback. The loop might be a day, a week, or a month. Work starts with a conversation about what is most valuable to learn or deliver next. The team selects a small slice of work, builds it, tests it, and puts it in front of users or stakeholders. The feedback informs the next slice. There is no required ceremony, but there is a required rhythm: decide, build, learn, adjust. The cycle ends when the team has something real to show, not when a meeting is over. The emphasis is on shortening the loop so that mistakes are cheap and discoveries are early.
In Scrum, one cycle is a sprint. The product owner maintains a product backlog ordered by value. At sprint planning, the team selects a sprint goal and a set of backlog items it believes it can finish within the sprint. The sprint backlog is the plan for that sprint. During the sprint, the team meets daily to coordinate and surface impediments. The work is designed, built, tested, and integrated into an increment that meets the definition of done. At the sprint review, the team shows the increment to stakeholders and collects feedback. At the retrospective, the team reflects on how it worked and chooses improvements. The sprint ends on a fixed date, even if some work is not finished. Unfinished work returns to the product backlog.
In Kanban, a cycle is the journey of a single work item across the board. Work is pulled, not pushed. When a column has capacity under its work-in-progress limit, the team pulls the next item from the previous column. The item moves from ready to in progress to review to done, following explicit policies at each stage. There is no required sprint boundary. Instead, the team may hold a replenishment meeting to decide what to pull next, and a periodic review to examine flow metrics and adjust limits. The cycle ends when the item is done, and the next item begins. The rhythm is continuous, and the focus is on keeping work moving smoothly rather than batching it into iterations.
4 Roles and how they divide the work
Agile does not define roles. It defines values and principles, and it expects teams to organize themselves in whatever way delivers the best results. In practice, Agile teams often include people who do the work, people who represent the customer or product direction, and people who help remove obstacles. But those are descriptions, not titles. The division of labor is a team decision. One person might play multiple roles, and roles might shift over time. The important thing is that the team has the skills and authority to deliver working software and the access to customers or users needed to make good decisions. Without that, Agile values become aspirational rather than operational.
Scrum defines three roles. The product owner is accountable for maximizing the value of the product and for managing the product backlog. That includes ordering items, clarifying them, and deciding what to build next. The Scrum master is accountable for helping the team and the organization understand and apply Scrum. This is a coaching and facilitation role, not a project manager role. The development team is accountable for delivering the increment. It is self-organizing and cross-functional, meaning it has all the skills needed to turn backlog items into working software. The team decides how to do the work; the product owner decides what to do and in what order. The Scrum master helps the team improve its process and removes impediments.
Kanban does not require any roles. It is a method for managing flow, and it can be applied by a team with any existing structure. In practice, teams often designate a service delivery manager or flow manager who helps track metrics, facilitate replenishment, and coach the team on limiting work in progress. Some teams have a product owner or a prioritization group that decides what enters the board. Others let the team pull work directly from a queue. Because Kanban is less prescriptive, role clarity is something the team must create deliberately. If no one owns the policies or the limits, the board can become a passive display rather than an active control system.
5 Artifacts worth keeping
In Agile, the most valuable artifact is working software. Documentation still matters, but it is judged by whether it helps the team deliver and maintain the product. A lightweight product vision, a prioritized list of desired outcomes, and a definition of done are often useful. So are tests, because they encode decisions and protect against regression. The point is not to eliminate artifacts but to avoid producing them for their own sake. If a document does not change a decision or help someone build, test, or operate the software, it is a candidate for removal. Agile teams tend to keep artifacts that are close to the work: code, tests, deployment scripts, and short notes that capture decisions and their rationale.
Scrum defines three artifacts and one commitment for each. The product backlog is an ordered list of everything that might be needed in the product. Its commitment is the product goal, which describes a future state the product is trying to reach. The sprint backlog is the set of product backlog items selected for the sprint, plus a plan for delivering them. Its commitment is the sprint goal, a single objective for the sprint. The increment is the sum of all completed work that meets the definition of done. Its commitment is the definition of done, which is the team's shared understanding of what it means for work to be complete. These artifacts are designed to create transparency and focus. They are not paperwork; they are working tools.
Kanban's primary artifact is the board itself. A Kanban board visualizes the workflow, usually as columns representing stages such as ready, in progress, review, and done. Each column has a work-in-progress limit, which is an explicit policy about how many items can be in that stage at once. The board also shows the items themselves, often as cards with key information. Other useful artifacts include explicit policies for each stage, a definition of workflow, and flow metrics such as cycle time and throughput. These metrics are not for performance review; they are for understanding the system and improving it. A Kanban team may also keep a service-level expectation, which describes how long different types of work typically take. The board and its policies are living artifacts that change as the team learns.
6 Where this method breaks down
Agile breaks down when it is treated as a label rather than a set of values. Teams may say they are Agile while continuing to work in long batches, avoiding customer feedback, and resisting change. The values are easy to recite and hard to practice. Without concrete practices, Agile can become vague. Teams may hold standups and retrospectives but never change anything. Or they may use the language of Agile to justify a lack of planning, which leads to chaos rather than adaptability. Agile also struggles in organizations that reward utilization over outcomes, because it asks people to spend time learning and collaborating, which can look like idle time on a traditional accounting report. The method is not a cure for a culture that punishes transparency.
Scrum breaks down when it becomes ritualistic. The ceremonies can be performed mechanically, with no real inspection or adaptation. Sprint planning can become a negotiation over how much work can be crammed into the sprint. The daily scrum can become a status report to a manager. The review can become a demo with no honest feedback. The retrospective can become a list of complaints with no follow-through. Scrum also struggles when the product owner lacks authority or access to customers, because then the backlog becomes a guess. And it can be inflexible when urgent work arrives mid-sprint. Scrum's answer is to protect the sprint goal, but in some contexts that protection is unrealistic. The framework assumes that the team can focus for the length of the sprint, which is not always true.
Kanban breaks down when it lacks discipline. A board without work-in-progress limits is just a visual to-do list. A team can move cards around without changing how work actually flows. Kanban also lacks a built-in cadence for strategic reflection. Without a regular review, the team may optimize locally and miss the bigger picture. It can also be difficult to introduce in organizations that expect fixed commitments and detailed long-term plans, because Kanban emphasizes continuous flow and probabilistic forecasting rather than date-driven promises. Finally, Kanban can allow too much work in progress if limits are set too high or ignored. The method depends on the team's willingness to say no to new work when the system is full, which is a cultural challenge as much as a technical one.
7 Frequently asked questions
Is Agile the same as Scrum? No. Agile is a set of values and principles. Scrum is a framework that implements some of those values through specific roles, events, and artifacts. You can be Agile without Scrum, and you can do Scrum without being Agile if you ignore the values. The two are related but not interchangeable. Many teams use Scrum as a starting point and then adapt it. Others use Kanban or a homegrown approach. The label matters less than whether the team is delivering valuable software and learning from feedback.
Can you combine Scrum and Kanban? Yes, and many teams do. A common pattern is to use Scrum's roles and cadence while using Kanban's board and work-in-progress limits to manage flow within the sprint. This is sometimes called Scrumban, though the term is not standardized. The combination can work well because Scrum provides a rhythm for planning and reflection, while Kanban provides a visual system for limiting work in progress and exposing bottlenecks. The risk is that teams pick the parts they like and ignore the parts that challenge them, ending up with neither the discipline of Scrum nor the flow focus of Kanban.
Which method is best? There is no universal best. Agile is a stance, Scrum is a structured framework, and Kanban is a flow-based method. The right choice depends on the nature of the work, the stability of the team, the predictability required by the organization, and the team's willingness to inspect and adapt. A team with rapidly changing priorities might prefer Kanban's continuous flow. A team that needs a regular cadence for planning and review might prefer Scrum. A team that already has strong delivery habits might only need Agile values and a few lightweight practices. The honest answer is to start with the problem you are trying to solve, choose the constraints that help, and be willing to change them when they stop helping.