There’s more than one way to incorporate Agile into your product development process. Thanks to countless coaches, gurus, and books on the subject, there are many systems to do it. But the two most popular approaches to bringing Agile to life and into practice are Kanban and Scrum. This article won’t tell you which one you should choose—and possibly, it’s not your choice, anyway.
Instead, we’re going to explain what they are and how they differ so you can hold your own when talking shop with coworkers or interviewing for a new product management role. Moreover, if one seems preferable to the other, you can use this as your starting point to convince whoever calls the shots in your shop that maybe they should give your favorite a try.
What is Kanban?
Kanban is a highly visual way of executing Agile. It’s practically synonymous with its eponymous artifact, the Kanban Board, which has taken on a life beyond Agile product development. In fact, “Kanban” in Japanese means “billboard” or “signboard.”
It was developed by Toyota to support its just-in-time manufacturing process, leading to the Lean approach. It emphasizes demand-driven development, which minimizes waste.
What separates Kanban from some other processes is that it doesn’t require you to blow everything up and start over. It can be superimposed on top of what’s happening now and visualizing things, slowly introducing incremental changes to make development more efficient. While this may eventually lead to substantial shifts in how organizations function, it’s not disruptive and doesn’t force staff to make any uncomfortable changes.
The Kanban Board puts every project, initiative, and feature into one of the columns. The most straightforward boards have three columns:
- Requested/To Do
- In Progress
With this minimal sorting of work, everyone knows the status of every item under consideration. When something exits the “In Progress” column, another item can take its place. It avoids having too many items in progress, which might overload development resources.
Add additional columns to the Kanban Board to add more granularity to each of those fundamental phases. For example, within “In Progress”, there could be sub-categories such as “Design,” “Development,” and “Testing.” But the fundamentals remain, limiting how many are in each stage.
What is Scrum?
Scrum is a rigorous Agile framework for project management. There is a Scrum Master assigning work, managing schedules, and troubleshooting challenges that arise, and there is often a Product Owner, who represents the business and the customer. They help guide the self-organizing development teams who are semi-autonomous to complete the tasks at hand.
It “chunks up” the work to be done into Sprints, typically one-to-four week-long bursts of development, often resulting in a release of new functionality. Not every initiative is finished in a single Sprint, but ideally, you wrap up portions or phases of those items in each Sprint.
Before they begin, the goals for each Sprint are determined in Sprint Planning meetings. Each Sprint has a Sprint Backlog of projects targeted for completion (or significant progress during each Sprint). Afterward, you hold Sprint Retrospectives to improve the process and communication continually.
What is the Difference Between Kanban vs. Scrum?
Kanban and Scrum vary significantly from each other in certain respects, although they’re not completely incompatible—there’s even a Scrumban framework that takes the best of each and merges them.
But many of the attributes of these two philosophies stand in stark contrast with one another.
1. Wholesale vs. incremental change
No one “dips their toes” into Scrum; it’s a wholesale shift to an entirely new way of delivering projects. For organizations that feel “broken” or need a seismic shakeup, it could be just the thing to turn things around.
But for companies that are generally happy with how things work, Kanban is an incremental, non-disruptive methodology.
2. Who does what
Rolling out Scrum requires significant organizational changes and likely the creation of new roles, which might even require hiring new people with relevant expertise. You need Scrum Masters and Product Owners for every development team, and an Agile Coach might be required to help stand things up and implement this new paradigm.
On the other hand, Kanban doesn’t necessitate any changes in staffing, roles, or responsibilities other than deciding who “owns” the Kanban Board.
Neither Scrum nor Kanban dictate how organizations prioritize projects and initiatives. However, the Sprint nature of Scrum may impact how many items can be worked on simultaneously, given the short window of working time available. It could drive prioritization decisions, as it’s easier to crank out smaller projects in a single Sprint than tie a Scrum team up for multiple Sprints on a longer one.
Kanban also limits how many things can be “In Progress” simultaneously, but these decisions aren’t based on development windows or Spring length.
Both Kanban and Scrum are “pull-forward” frameworks; you don’t start something new until you finish something else. The big difference is things in Kanban are done when they’re done, while Scrum uses Sprints to break down the work, creating a much more predictable environment.
Depending on the size of each project and the number of development resources, this might mean Kanban has more frequent or fewer releases than a Scrum organization with a set two-week cadence.
It all comes down to bandwidth and scope. If projects only take a couple of days, in Kanban, it’s ready to go, while in Scrum, it might sit on a shelf until the rest of the Sprint is complete. If it’s a bigger project, it might be months between releases in Kanban, while Scrum will produce incremental work each Sprint.
Scrum also requires very precise scoping and estimation to fit projects into Sprints. Kanban doesn’t necessitate this, as projects aren’t timeboxed.
While product success metrics don’t vary with either approach, measuring how well product development is going differs. Both will care about customer satisfaction, defect rates, and the like, but other metrics are distinctive for each method.
Scrum uses metrics such as velocity to determine how well things are moving through the process along with Sprint Goal Success (i.e., how much of what the team set out to do for the Sprint happened).
Kanban doesn’t have rigid measures, but it uses the lead time to see how well the development team is cranking through the list of items waiting to be built. Cycle times (how long it takes a project to get through the entire process) is another common metric, as is throughput, which looks at how much total work is you’re producing in a given period.
6. Change philosophy
In Scrum, when the Sprint is locked, it’s locked. Nothing’s getting added; nothing’s getting dropped. Late-breaking developments must wait for the next Sprint to kick in.
There’s no such limitation for Kanban, so modifications to scope, requirements, etc., can occur while things are working actively on.
Pros and Cons to Kanban vs. Scrum
Neither methodology is going to fit perfectly, so it’s worthwhile to examine the pluses and minuses of both.
- Alignment – Kanban boards keep everyone on the same page.
- Exposing chokepoints and bottlenecks – When columns start getting too long, they indicate a disconnect between resources and demand.
- No hard-and-fast rules – True flexibility regarding prioritization, decision-making, what processes are necessary to enter or exit each stage
- Flexibility – The queue of work to be done can be rearranged and reprioritized based on new data and strategic inputs without impacting the rest of the product development workflow.
- Timeless – Kanban boards have no dates. Additionally, there’s no way to know if an item is one day or three months away from exiting to the next column within a particular stage.
- Potentially outdated – Like any artifact, if you don’t update the Kanban Board, it’s not accurately reflecting things.
- Understandable – Scrum has no shortage of firmly established and documented processes, nomenclatures, processes, and timelines.
- Rapid feedback – Because Sprints are so short, and there’s ample opportunity to release things, get input, and incorporate it into a future Sprint. Plus, there’s flexibility regarding what the team will work on in the next Sprint right up until it begins.
- Daily meetings – The ceremonies of Scrum (including daily standups) mean issues don’t fester for long as everyone’s interacting daily to discuss things.
- Inflexible – True Scrum is very strict about how things happen and who can be involved.
- Constant pressure – The short length and rapid frequency of Sprints can be exhausting and doesn’t allow time to “breathe.”
Scrum and Kanban tools
No matter which Agile path you pursue, there’s no shortage of tools to help teams stay organized, communicate, and execute. For example, Jira is built for the Scrum crowd, while Trello is a super-powered Kanban Board.
Neither methodology replaces the need for a product roadmap. So there must be a tight integration between these planning and execution tools and what product teams use for roadmaps.
Both Jira and Trello integrate seamlessly with ProductPlan to ensure product roadmaps don’t fall out of date when things change. You can also use the List View in ProductPlan to create and maintain a Kanban Board right in the same tool!
To learn even more about Agile and its many variants and options for implementation, check our free book.