Teams using Scrum often struggle with operational or emergent work blowing up their Sprint plans. If production is down, nobody will care about that sexy new feature your team is developing.
By combining the disciplines of Scrum and Kanban, our teams can find a happy balance between planned work and emergent work while continuing to maintain discipline and continuous improvement.
Build your foundation in Agile values.
The first values in the Agile Manifesto are:
“Individuals and interactions over processes and tools”
When selecting a framework, focus first on the people delivering the value. The tool selection should be secondary to that.
Both Scrum and Kanban exist to help teams deliver value in their organizations. Therefore they should not be seen as an end, in and of themselves, but rather a means of delivering.
So, Scrum or Kanban?
Many believe that we must choose a side in the Scrum vs Kanban debate.
Scrum’s sweet spot is new product development. Scrum is a simple, lightweight agile framework that employs an iterative, incremental approach to value delivery where all requirements are captured as items in a product backlog, product progresses in a series of time-bound Sprints (also called Iterations) that is tracked through metrics and visible charts, and the resulting product increment is demonstrated at each Sprint boundary.
Kanban is an increasingly popular Lean-inspired agile method that respects the existing situation, processes, roles, and helps you improve from where you are. Kanban advocates evolutionary change by visualizing all work, limiting work in progress, and maximizing value flow.
While Scrum is based on short, structured Sprints with value delivered at the end of the Sprint, value flow in the Kanban method is continuous and fluid.
Do we HAVE to choose one over the other?
Kanban gives us a set of processes and practices as a good place to start. Scrum gives us a basic recipe of three roles, five events, and three artifacts. Both methods require the teams to engage in continuous learning and improvement.
I guarantee that some of us are really excited about a particular method.
“Scrum is the absolute best! You have to use Scrum to deliver!”
Or
“Kanban is the absolute best! You have to use Kanban to deliver!”
And both are right; there is no best method. Either method can be thought of as a starting recipe that you build on and modify over time.
Bottom line: a context-sensitive blend is the best.
You can blend techniques from Extreme Programming, DevOps, Lean Startup or other methods such as:
- Story Point Estimation
- Test Driven Development (TDD)
- Continuous Integration
- Continuous Delivery
- Customer Discovery
- Weighted Shortest Job First Prioritization (WSJF)
Adopting these techniques into Scrum or Kanban does not violate either method. If they help, continue using them; if not, dump them.
If you employ retros, team building and coaching, there’s a lot more information out there in the Scrum community.
If you use flow based metrics, root cause analysis, visual management and optimization techniques, you should go to the Lean and Kanban community.
Which brings us to ScrumBan – an optimum blend between Scrum and Kanban
While I’m not crazy about mixing chocolate and peanut butter, some believe these are “two great flavors that taste great together”.
Let’s look at a basic recipe for ScrumBan. It’s certainly not the only recipe, but it is the one with which I usually begin. In the image below, the items in green come from Scrum and the items in blue come from Kanban.
Our blend has configured Kanban by adding the following things from Scrum:
- Layer on a Sprint/Iteration cadence
- Adopt Sprint Planning, Daily Scrum, Sprint Review and Sprint Retro
- Use the Scrum roles of Product Owner (PO), Developers and ScrumMaster (SM) (many rename the ScrumMaster to Agile Coach in ScrumBan)
We have configured Scrum by adding the following things from Kanban:
- Reserved a planning buffer for unplanned work
- Use pull for unplanned work
- Use a Kanban board with explicit policies such as Work in Progress (WIP) limits
It could easily be argued that ScrumBan is a perfectly valid implementation of Scrum or Kanban and that we do not need the word ScrumBan. If we find ourselves arguing over words rather than focusing on delivery we have lost the essence of Agile.
What’s next and how can I learn more?
The best way to learn is by doing. So go out and experiment!
As you experiment, stay focused on flow of value and continuous improvement.
Now, that is truly Agile.
Resources:
- Scrumban – Effectively combining Scrum and Kanban – Bob Payne – https://www.youtube.com/watch?v=TFEl5TdUSbw
- Scrum vs Kanban vs ScrumBan – https://www.youtube.com/watch?v=VgdL5AnxVp8
- Scrum to Scrumban in 6 steps – https://www.youtube.com/watch?v=fgT4AaKcBUA
- Scrumban – Corey Ladas – https://www.amazon.com/Scrumban-Systems-Software-Development-Cooperandi/dp/0578002140
