02.06.19 | Chris Daily |
It happens quite often: I have somebody ask me if Kanban is more suited for their organization.
When I dig in to try to understand where the question is coming from, I often get a response that Kanban will be easier for the organization to adopt because it doesn’t have the commitment to a two to four-week duration that Scrum does.
The typical follow-up comment is that Kanban also doesn’t have all the meetings that Scrum does.
One Size Doesn’t Fit All
As many of you know, Kanban comes from manufacturing and is a workflow system whose strength is visual workflow management.
Originally based using cards, its focus is on ensuring that work items flow through boards with lanes that represent process stages.
Teams using Kanban continuously plan, work, review, and measure the outcomes of their work. By limiting the number of items being worked at any one time, teams are more focused, and the complexity of the work is substantially reduced by incorporation Work-In-Process (WIP) limits.
Building on its manufacturing roots, Kanban teams measure lead time, cycle time, and use those measures to optimize their process with the goal of continuously delivering a predictable flow of value to customers.
In many ways, Kanban teams are more mature in their Agile maturity than teams that have adopted Scrum. As a stepping stone towards Kanban, teams will incorporate both Scrum and Kanban at the same time, which is often referred to as Scrumban.
Scrumban: Utilizing Benefits of Two Frameworks
Scrumban is used by teams who need the structure of continuous improvement incorporated in Scrum with the flexibility that a flow-based method such as Kanban offers.
For teams already using the Scrum framework, there are minor variations to the Scrum roles, events, and artifacts. The Sprint Planning event is one example of a slight variation. Teams using the Scrum framework enter the Sprint Planning event with the objective of, based on the order, identifying the Product Backlog items that will be completed in the upcoming Sprint. The artifact that is created is the Sprint Backlog, which essentially becomes the work plan of the Development Team during the sprint.
Scrumban incorporates the pull approach of Kanban: the team starts work when it can; therefore less emphasis is placed on forecasting what work will be completed by the end of the Sprint.
For a list of all the variations, you can download our beLithe Scrum vs. Kanban vs. Scrumban cheat sheet.
Putting Our Ramblings Into Action
Scrumban is an Agile process that is a valuable tool to help a team when Scrum or Kanban alone don’t solve the problem.
Retaining the intent of Scrum while allowing for the flexibility and transparency of Kanban make Scrumban a powerful tool.
While many find it helpful in teams that provide services to other teams, I have seen that teams in areas outside of IT and software development (HR, Accounting, Marketing, Customer Support, and Sales) can benefit from using Scrumban.
The risk is low, so don’t be afraid to experiment for a Sprint or two. Given the minor differences, it’s easy to step on into Scrum or Kanban.
Are you currently adopting Scrumban? I’d love to hear how you’re implementing it. Drop me a line.
Thanks for coming in today.
Chris
Let’s connect.
Instagram | Facebook | LinkedIn | Twitter | www.beLithe.com
Both Scrum and Kanban belongs to the same methodology i.e. Agile. Though both these terms have subtle differences between them, the principles are the same, meaning both will help to build better products and services.
Also, there is this one thing that they have in common, that is, both are known as pull systems. This pull system makes sure that the work gets from the product backlog to customers in the shortest period time. But both the Scrum and the Kanban implement the pull system in two different ways.
So whatever the methodology you choose, just make sure that you are clear on the principles.