Kanban and Scrum are agile methodologies that help teams visualize and significantly improve software development processes to build better products and services. When choosing between Kanban or Scrum, is important to know that both frameworks follow the same principles but there are some important distinctions that you’ll want to consider.
The Kanban System
Teams open to adopting a spirit of continuous improvement "Kaizen" adopt a Kanban mindset. Kanban, being the concept of incremental progress and improvements, does not prescribe a certain philosophy or setup. This means anyone can use Kanban.
This also makes it very easy for any team to introduce Kanban concepts, as no sweeping process changes need to be made.
Teams that adopt Kanban principles agree:
- To pursue incremental, positive changes to get better over time. Kanban encourages teams to continuously ask and challenge things that aren’t working, or if they are, are there ways to get even better.
- To respect current processes, responsibilities, and ways of working, but are flexible to change. Kanban encourages value in the existing, but challenges teams to always have an eye for change. Change should only be implemented if the team agrees that it will introduce positive progress to move everyone forward, together.
- Small changes are easier and better. Incremental course corrections are less disruptive to team needs. Altering the complete process is not the aim of a Kanban mindset, as larger changes are disruptive.
- That everyone is empowered to be a leader and encourage change. No one individual should need to hold an executive or team lead title to bring forth change, ideas, or have a focus on team improvement. Kaizen, a concept heavily embedded in Kanban, inspires everyone to be looking out for how the team can optimally perform, together.
- Work should be collaborative, and visual. With the goal being positive change, optimizing workflow habits is a key reason to visualize work the team is working on. Visualizing work in a collective Board also ensures no changes are made before the team understands how work flows. This puts the focus on shared understanding before actioning change.
What is a Kanban Board?
A Kanban board is a tool designed to help visualize work. Making work visible helps show others what’s going on, what’s upcoming, and keeps everyone on the same page.
Teams just getting started might use a tech-less process using sticky notes and physical Boards in co-located spaces. Others use products like ZenHub to organize work. Online Boards are helpful for distributed teams, or those teams looking to enhance the physical sticky note process (such as being able to identify dependencies between work).
Here's a few reasons why using ZenHub’s Kanban board as an online Board is preferred by teams:
- Speeds up the amount of time to set it up, keep it maintained, and readily available
- Ease of sharing it with others, especially stakeholders invested in the delivery of work
- Provides a home to asynchronously track an infinite number of Issues, tasks, projects, and conversations
- No matter where or when teams look at the Board, they’ll see the most up-to-date status of work
- Supports distributed teams and updates when physical location cannot be guaranteed
Kanban Boards have many elements
Each Board created has various visual elements, including:
Workflow stages (columns, or pipelines)
Issue or task cards: Issues represent a piece of work. For most teams, each Issues represents a task to be complete. Once visualized through an Issue, it gets placed in pipelines.
Work in progress limits: how much work your team has in progress between committed to and delivered. WIP limits are also known as the maximum number of Issues that the team ideally would like to have in each column at any given time to avoid context switching.
Commitment stage: The pipeline/stage that signals work is being committed to being delivered and agreed upon by the team.
Delivery stage: The pipeline/stage that signals work is finished. Ideally, teams should aim to have the time between an Issue being committed to, and delivered, as small as possible. The elapsed time between the two is called lead time. Teams should always be aiming to decrease their lead time as much as possible.
Issues on a Kanban Board through flow through the workflow until completed, moving left-to-right. Boards can be as simple as New, To Do, In Progress, and Complete or quite complex including stages from product, to design, and further to development. ZenHub is flexible and easy to change, so as your workflow changes, your pipelines can too.
What's the difference between Kanban and Scrum?
Both Kanban and Scrum share some of the same principles, including:
- Both are visual
- Teams practicing either are self-organized
- Both focus on the concept of continuous improvement, uncovering bottlenecks
- Both create future commitments, aiming to be as accurate as possible with delivery of work
However, they also have distinct differences, including:
Scrum practices the concept of Sprints, which have start/end dates. Where as Kanban is an ongoing process.
Kanban inspires work in progress limits but has no formal process where by work is "committed to" within a set duration of time, like a Sprint. Instead, everything is continuously planned in Kanban, and picked up as work in progress moves to completion.
Scrum uses estimation via story points to track the complexity of work. Kanban doesn’t measure the complexity of work as strictly, but rather encourages work not being started until other work has finished.
Teams that practice Scrum will typically have team members with designated roles and responsibilities, such as product owners scrum masters. Kanban has no formal roles.
Getting Started with Kanban
Good news! If you’re using ZenHub today, you’re already practicing Kanban :)
You’re committing to:
- Mapping your current workflow, visually
- Focusing on the flow of work through your team’s workflow
- Introducing processes to unblock team members and focus on the commitment of quality work
To introduce even more Kanban principles in your team’s workflow you can:
- Look to introduce work in progress limits
- Create a shared process for continuously discussing (having a retro, for example) how productive the way the team works is: Every month have a team retro on what is working, and what is not when it comes to moving work from commitment to delivery stages. Focus on team processes, productivity, and micro-changes.
Learn more about how ZenHub can bring agile project management to your software teams today!