Learn About Kanban
After completing this unit, you’ll be able to:
- Describe the four key traits of Kanban.
- List how progress is measured and predicted with Kanban processes.
- Describe how Kanban embraces change in priorities.
Salesforce takes parts of Scrum and applies it to another framework we use: Kanban. This is a method for the more infrastructure or operations-focused teams that support production or customer issues use.
Generally speaking, Kanban is less prescriptive than Scrum, making it easier to implement. At Salesforce, even if a team adopts the Kanban process, they still use the same roles and meetings of Scrum (read units above), because they’re proven to be good practices. This is called Scrumban!
But Kanban is still very different than Scrum. Here are four key traits of Kanban.
- Visualize workflow: Work is divided up into pieces, each written onto a card that is placed on a wall (either physical or virtual). At Salesforce, we use a virtual wall, called Agile Accelerator.The workflow is mapped into columns, illustrating where each item is in the workflow.
- Limit work in progress (WIP): Teams place limitations on how many work items are in progress at one time in each workflow stage. If they hit a limit, they help each other out by tackling things as a team to unblock them.
- Incremental and evolutionary change: Unlike Scrum, which is a process that calls for far-reaching shifts in work process, Kanban lets teams embrace smaller and more changes along the way.
- Kanban includes metrics: There are a few measurement systems used in Kanban: Lead time, which is the average time to complete one item, sometimes called cycle time. This helps teams optimize the process to make lead time as small and predictable as possible. Throughput: Defined as the amount of work completed in a single period of time.
One of the basic elements of Kanban is to make everything visible, creating consistent transparency of work items. The process is based on the Kanban card, which in Japanese means visible sign.
With Kanban, when a team completes a stage, a card is moved to the next stage, indicating completion. Here’s what that looks like.
Scrum works by limiting the amount of work per sprint (every 2 weeks), while Kanban limits the amount of work per workflow state—there is no set timeframe for this, but it is measured. We use WIP limits to prevent bottlenecks, boost overall efficiency, and prevent unfinished work, just like in Scrum.
The WIP limits are there to help the team set realistic goals based on its capacity and bandwidth. Of course, all of that can change at any time, and teams are always ready to pivot (it’s part of being agile!).
Anytime a team takes on new work, members get together and ask: “What do we want our WIP limit to be?” That’s where the fun comes in: Experiment! Set a WIP limit, and see how it works (or doesn’t) for your team. You can always adjust at your next retrospective meeting.
Imagine this scenario: A stakeholder wants your team to deliver a high-priority item right now. If you’re using Scrum, the team always says: “No thank you, put it on the product backlog to be prioritized.” That’s what Scrum is for: to protect the team from taking on new work while in the middle of a sprint.
But with Kanban, the team can respond to the same stakeholder with, “OK, we have a WIP limit of two—we can start on this urgent item next.”
Kanban teams do not make the same commitments—and they don’t have sprint backlogs. In other words, teams using this workflow are more open to taking on a last-minute request. When they’re finished with a work item, they move to the next highest-priority task.
How do we predict and determine our progress using Kanban? We measure. Kanban metrics rely on average lead times to determine our output. In other words: How long does it take for an item of work to completely pass through all of the work states before it’s considered done?
Just a quick note: If your lead times start to increase, have a look at what’s going wrong with your process.
Since all work is highly transparent in a Kanban system, it’s easy for teams to know when delays occur—and they react quickly. As delays occur, teams hash out root causes of those delays, looking for ways to improve their cycle times or reduce their bottlenecks in the future.
These are all the Kanban principles teams use to efficiently deliver value to customers. But which is best between Scrum or Kanban? We talk about the different types of work and which framework teams tend to use at Salesforce in the next unit.