Uncover the key considerations when choosing between scrum or kanban, and what to do if you can’t decide.
Summary: Kanban is a project management framework that relies on visual tasks to manage workflows, while scrum is a project management framework that helps teams structure and manage their work through a set of values, principles, and practices. Agile is a set of ideals and principles that serve as our north star. DevOps is a way to automate and integrate the processes between software development and operations teams. When it comes to implementing agile and DevOps, kanban and scrum provide different ways to do so. It’s easy to point out the differences between scrum practices and kanban practices, but that’s just at the surface level. While the practices differ, the principles are largely the same. Both frameworks will help you build better products (and services) with fewer headaches.
“Don’t ask, “kanban vs scrum.” Instead, ask “kanban or scrum” or even “kanban and scrum.” Make it more about the principles than the practices.”
So, where were we?
Agile is a structured and iterative approach to project management and product development. It recognizes the volatility of product development, and provides a methodology for self-organizing teams to respond to change without going off the rails. Today, agile is hardly a competitive advantage. No one has the luxury to develop a product for years or even months in a black box. This means it’s more important than ever to get it right. Kanban is all about visualizing your work, limiting work in progress, and maximizing efficiency (or flow).
Kanban teams focus on reducing the time a project takes (or user story) from start to finish. They do this by using a kanban board and continuously improving their flow of work. Scrum teams commit to completing an increment of work, which is potentially shippable, through set intervals called sprints. Their goal is to create learning loops to quickly gather and integrate customer feedback. Scrum teams adopt specific roles, create special artifacts, and hold regular ceremonies to keep things moving forward.
Scrum is best defined in The Scrum Guide. Whichever project management framework works best for you, we can easily find templates that cover your need.
Scrum: A structured agile approach
With scrum, your team promises to ship some valuable increment of work by the end of each sprint. Scrum is built on empiricism, focusing on small increments of work that will help you learn from your customers and better inform what you do next. Here’s how it breaks down:
Scrum cadence
Scrum moves fast, with sprints that usually last between one to four weeks, which have clear start and finish dates. The short time frame forces complex tasks to be split into smaller stories and help your team learn quickly. A key question is this: Can your team ship useable code that fast? Sprints are punctuated by sprint planning, sprint review, and retrospective meetings and peppered with daily scrum (standup) meetings. These scrum ceremonies are lightweight and run on a continuous basis.
Scrum roles
Scrum has three clearly defined roles.
- The product owner advocates for the customer, manages the product backlog, and helps prioritize the work done by the development team.
- The scrum master helps the team stay grounded in the scrum principles.
- The development team chooses the work to be done, delivers increments, and demonstrates collective accountability.
Who manages the scrum team? Well, nobody. Scrum teams are self-organizing and everyone is equal, despite having different responsibilities. The team is united by the goal of shipping value to customers.
Common metrics
Scrum metrics are data points scrum teams can use to improve efficiency and effectiveness. They can inform decision-making and help teams become more efficient in planning and execution. During the sprint planning phase, teams can use metrics such as sprint goals, team velocity, team capacity, and type of work. During stand-ups, teams can also benefit from measuring progress towards sprint goals, reviewing a sprint burndown, understanding workload distribution, and more.
Change philosophy
Teams strive to understand how much they can accomplish within their sprint time boundaries. They commit to its delivery within a sprint. However, scrum teams can receive customer feedback that encourages them to pivot and change the sprint to deliver the most customer value. During the sprint retrospective, scrum teams should discuss how to limit change in the future, as changes put the potentially shippable increment at risk. If a team frequently changes scope mid-sprint, it may signify work was selected that isn’t adequately understood. It could also mean the team has operational/unplannable work that interferes with the plan.
Kanban: Continuous improvement, flexible processes
Kanban helps visualize your work, limit work-in-progress (WIP) and quickly move work from “Doing” to “Done.” Kanban is great for teams that have lots of incoming requests that vary in priority and size. Whereas scrum processes require high control over what is in scope, kanban let’s you go with the flow. Let’s take a look at the same five considerations to help you decide.
Kanban cadence
Kanban is based on a continuous workflow structure that keeps teams nimble and ready to adapt to changing priorities. Work items—represented by cards— are organized on a kanban board where they flow from one stage of the workflow(column) to the next. Common workflow stages are To Do, In Progress, In Review, Blocked, and Done. But that’s boring.
The best part of kanban is making custom columns for how your team works. My team ships content, so our columns (simplified) go from Backlog, to Prioritized, to Outlines Ready, to Writing, Designing, Technical Review, and Shipped. Our board helped us learn that we ship about one piece of content per week, and where our bottlenecks are (looking at the Technical Review!).
Release methodology
In kanban, updates are released whenever they are ready, without a regular schedule or predetermined due dates.
In theory, kanban does not prescribe a fixed time to deliver a task. If the task gets completed earlier (or later), it can be released as needed without having to wait for a release milestone like sprint review.
Kanban roles
The whole team owns the kanban board. Some teams enlist an agile coach but, unlike scrum, there is no single “kanban master” who keeps everything running smoothly. It’s the collective responsibility of the entire team to collaborate on and deliver the tasks on the board.
Key metrics
Lead time and cycle time are important metrics for kanban teams. The deal with the average amount of time that it takes for a task to move from start to finish. Improving cycle times indicates the success of kanban teams.
The Cumulative Flow Diagram (CFD) is another analytical tool used by kanban teams to understand the number of work items in each state. CFDs help identify specific bottlenecks that need to be resolved for better throughput.
Another way to deal with bottlenecks is through Work In Progress (WIP) limits. A WIP limit caps the number of cards that can be in any one column at one time.
Change philosophy
A kanban workflow can change at any time. New work items can get added to the backlog and existing cards can get blocked or removed based on prioritization. Also, if the team capacity changes, WIP limit can be recalibrated and work items adjusted accordingly. It’s all about being flexible in kanban.
Scrum tools vs. kanban tools
The agile community believes this conversation shouldn’t be about the tools. We often see the tool of choice driving the framework of choice and the framework driving the principles the team adopts. We believe the decision should flow in the other direction.
Once you’re aligned on scrum principles and happy with the scrum framework, then it’s time to find a scrum tool that serves you well. The same goes for kanban.
Kanban vs. scrum: What if you can’t choose?
Scrum and kanban are “agile by-the-books.” They work in a tried and true fashion that is quite frankly hard to argue against. Borrowing from another famed catch-phrase, you might say that, “No one gets fired for choosing scrum.”
But your decision doesn’t need to be so black and white. Hundreds of teams are using hybrid models influenced by both scrum and kanban.
Team-managed projects, as the name suggests, allow teams to pick and choose the agile features that make sense for them; whether that’s scrum, kanban, or a mix of both. Instead of implementing one framework on day one, team-managed projects allow you to progressively layer on more and more powerful features as you learn what works for your team (and what doesn’t).
You can confidently choose team-managed scrum or team-managed kanban knowing that both templates can evolve to suit the needs of your team.
Regardless of what you choose, stick with it for a little while. Take some work from the backlog all the way to done and then ask your team what went well and what went poorly. By trying scrum and kanban and asking these questions, you’re well on your way to agile bliss.
