Production teams have had to be quick on their figurative feet—perhaps even agile—in order to meet the expectations of the markets they serve. But improving efficiency, reducing time-to-market, and minimizing workload are all considerable challenges on their own, let alone achieving all of them simultaneously.
So even when teams are trying to make the most of an Agile approach, it’s not always clear how to do that.
That’s where Agile methodologies like Scrum and Kanban come in. A well-defined framework can provide the needed structure to get the team on track. Let’s talk about how and when to use these two.
Agile methodologies
Agile is all the rage these days. It helps businesses pursue better customer service and better software development without working dev teams to the bone. But originally, Agile was just that: guidelines. The Agile Manifesto is a collection of principles rather than a how-to manual.
Implementing those ideals is done primarily via structured project management approaches designed to prioritize those key Agile objectives.
Think of it like an architect’s blueprint, designed to adhere to building codes. These “blueprints”—sometimes referred to as methodologies, or frameworks, provide the guidance and tactical processes for teams running on Agile.
Scrum and kanban are two such methodologies (or frameworks, or approaches, or…), and are among the most widely used. Like all Agile-centric systems, they share core objectives, and a number of key features. In fact, some of the “differences” can be incredibly granular. But they can make more of a difference than you might expect.
Here are some of the high-level similarities:
- Prioritizes support of continuous development and implementing user feedback
- Minimizes both overload and underload to more efficiently apply labor hours
- Speeds production of highest priority tasks, decreasing delivery time to users
- Facilitates ongoing evaluation of both product and process
- Now, let’s dig into the nitty-gritty of how they differ.
ALSO READ: 6 Customizable Software Tools for Agile Project Management
Scrum—Sprinting for professionals
If you’ve heard an acquaintance talk about their “Scrum master” or “completing a sprint,” then this is the system they were using (…probably). Scrum is structured around clearly defined responsibilities and fixed-length production periods. Here’s the breakdown:
Foundational concepts of Scrum
- Organize teams to provide structure, transparency, and responsibility for ongoing individual tasks
- Prevent bottleneck and scope creep by subdividing productivity periods and separating projects into “sprintable” tasks
Key features of Scrum
- Fixed-length, recurring production periods (“sprints”)
- Designated roles that determine sprint/task-specific responsibility (product owner, Scrum master, etc.)
- Regularly scheduled, efficient meetings (sprint planning, daily Scrum, sprint review, etc.)
Scrum—How it’s done
Scrum teams live and die by their production intervals. Called “sprints,” these fixed-length, recurring timeframes define the boundaries of what teams can commit to, project-wise. Different teams use different sprint lengths (most commonly two weeks, or one month), but once a sprint length is picked, each sprint is the same length.
The predetermined, immutable time period is critical, because tasks have to fit within a sprint, or they don’t go on the schedule. If the project is too big, it has to be broken down into smaller objectives that can—individually—be achieved within a single sprint.
Sprints are managed and supervised using a number of defined roles that determine which team member is responsible for what. This helps achieve transparency and accountability, though not every organization divvies up the delegations the same way. The two roles that are almost universal are the product owner and the Scrum master.
Product owners are responsible for the software itself—they decide what goes on the list of priorities, and they decide when projects are good enough to ship. Scrum masters are the productivity facilitators. They’re in charge of rallying the troops, organizing the efforts, and keeping the process running smoothly.
Finally, Scrum depends heavily on meetings. Each sprint begins with a planning session, each day starts with a review of the current task list (called a “standup” or “daily Scrum”), and each sprint ends with a review of how things went.
These meetings are designed to be as brief and succinct as possible. Remember, “sprint” is the name of the game, and any time spent sitting around a conference table is time not spent hitting the ground running at full speed.
Scrum in a nutshell: Scrum is like a bucket of water. Capacity is intentionally limited to encourage the rapid filling and emptying of the bucket. Each sprint should fill the bucket to capacity at the start, and drain it completely by the end.
Kanban—Success through sticky notes
While Scrum is structured around a communal motivational momentum, Kanban is centered around facilitating clarity through visual aids. “Kanban boards” are the hallmark of this system (though Scrum uses them too…more on that below), where upcoming, current, and completed tasks are represented on cards and organized in columns based on status.
If someone you know has a disproportionate affection for sticky notes, they’re likely a Kanban adherent.
Foundational concepts of Kanban
- Organize and manage production by using visualization aids when assigning tasks and tracking status
- Increase delivery speed while minimizing WIP via visualized organization
Key features of Kanban
- Visualization tools (usually involving sticky notes and a sizeable section of office wall)
- Continuous, rotating workflow with WIP limits, rather than distinct production periods
- No required roles (though roles are sometimes still used)
Kanban—How it’s done
Kanban doesn’t segment its timeframes the way Scrum does. Instead, Kanban boards are used to keep track of projects as they move from the priority list, to the current tasks, to the completed pile. Depending on teams and use cases, there may be just one work-in-progress column, or any number of them.
No matter the number, Kanban systems always place a hard limit on the number of active WIP tasks that are allowed. The number is also traditionally very small (most commonly between two and four). Each time a task is moved out of the WIP column, a new task is pulled from the priority list and added to the current tasks.
By nature, Kanban is more fluid, less rigid, and more continuous than Scrum. This allows for tasks that may take longer than a sprint can typically accommodate, without the work piling up (in theory, at least).
Kanban in a nutshell: there will always be more on the to-do list than hours in the day. Kanban is designed as a dam to keep the backlog from drowning the dev team. Overflow is carefully controlled, and the gates are only opened when there’s room downstream for the flow.
ALSO READ: What Is Scrumban?
Kanban vs Scrum: Side-by-side
| Scrum | Kanban | |
| Foundational Concepts |
|
|
| Key Features |
|
|
| In a Nutshell | Fill the bucket, dump the bucket, rinse, repeat | Steady, controlled, continuous flow |
Optimal use cases: When to use Scrum vs. Kanban
Despite their similarities, there are some pretty distinct differences between the two when it comes to where it’s best to use them.
Scrum, with its sprint intervals, regular meetings and evaluations, and regular clearing of the slate is heavily geared toward teams that are working on products. Any time a team has objectives that are clearly defined and finite, Scrum is the better option.
Here are some of the core needs it answers:
- Provides a built-in feedback system for evaluation and incorporating input from stakeholders (managers, customers, users, etc.)
- Offers team members a feeling of accomplishment and completion each time the slate is wiped clean
- Organizes efforts around major projects that can be considered “finished” and taken off the slate for good
Kanban, on the other hand, is better suited to work that is near-perpetual. Ongoing critical support, service tickets, and other “the job is never done” type efforts fall into this category. These aren’t one-and-done projects; this is a revolving door of to-do lists, where the objective isn’t to “finish,” it’s merely to keep up with the demand. Here are the highlights:
- Focuses on maintaining momentum for productivity and resolving open tasks
- Helps teams limit the burden and risk of burnout by limiting concurrent WIP objectives
- Minimizes the need for meetings or feedback when the priority is simply getting jobs completely quickly
In short, if you’re working on a programming team, dev team, or product team, Scrum is probably a better fit. If you’re in DevOps, IT, tech support, or similar, Kanban is the one for you.
Software recommendations for Kanban and Scrum
There are a lot of software tools that can help keep your team organized and on track, whether you’re using Scrum or Kanban.
If that’s something you’re looking for, here’s a few leading vendors to start your search:
Scrum software options
Kanban software options
“I’ve heard it both ways…”
The terms and jargon used in computer technology professions are notoriously discord-riddled. Even something as simple and ubiquitous as GIF doesn’t have universal pronunciation. But in some cases, there will be entirely separate alternative names for a given concept, tool, practice, technique, or other topic, and subjects related to Agile are no different.
Here are a few definitions to further clarify:
- Agile—A programming philosophy, or methodology, or a mindset, or a framework, or even an individual practitioner of Agile programming, depending on who and when you ask.
- Methodology—Either one of any number of principle-based programming approaches, such as Agile, extreme programming, adaptive software development, etc. OR one of the distinct implementations of such a system, such as Scrum and Kanban for Agile.
- Framework—Possibly equivalent to the first example of “methodology” as given above; possibly an equivalent to the second. Possibly neither.
- Kanban board—A visual aid consisting of a series of columns with labels such as “WIP,” “to-do,” “done,” etc. Columns are populated by individual cards (note cards, sticky notes, or similar writing surfaces) that track tasks as they move through the production process. Sometimes made using physical office supplies, sometimes rendered using a computer application. If you’ve seen a Trello board, you’ve seen a Kanban board. Paradoxically, while Kanban systems almost always use a Kanban board, so do other Agile-based implementations in many cases … including Scrum.
- Sprint—Either something you did for the last time in your final PE class you ever took, or something you’re destined to repeat for the rest of your professional career like Groundhog Day.
ALSO READ: Agile Project Management Buyer’a Guide
Scrum vs Kanban: Choosing what’s right for you
Effective processes are critical to efficiency, productivity, and scalability, especially in software engineering. And, like it or not, there’s no killer app that can compensate for chronically unorganized humans. Without solid, reliable procedures, the chaos remains.
So, provide your team with some structure. The right structure. Which structure is the right one? We can’t answer that any more decisively than we can answer “is it a methodology or a framework.” But hopefully this article has provided at least a little guidance. And besides—every team applies some tweaks to the formula rather than using it straight out of the box.
As long as you find a framework and structure that sets your team up for success, you can call it whatever you want. Looking for the latest in Project Management solutions? Check out our Project Management Software Guide.
Featured partners
Featured partners
FAQs
