This article is not an overview of Scrumban or how to use it. It is an overview of the intent of Scrumban and what it is based on. The best resource for Scrumban is still Corey Ladas’ Scrumban: Essays on Kanban Systems for Lean Software Development. This was the first publication on Kanban (Corey Ladas was one of the 5 co-creators of Kanban).
Corey was not a particular fan of Scrum. Having deep experience in Lean he saw Lean as the true base of what we should be doing. But he wasn’t attached to anything except what worked. He once personally told me “there is no Scrum, there is no Kanban, there is only Lean.”
So the first thing to understand is that Scrumban is not an extension of Scrum, but rather a team focused approach based on Lean that incorporates Scrum and Kanban. Scrumban is a process to achieve flow at the team level.
Scrumban’s main intent was to take people from Scrum to a flow method such as Kanban (hence the name). After a few years it was recognized that Scrumban stood as a process on its own feet. I had been using Scrumban for a couple of years as a replacement for Scrum when I asked Corey “I know the intent is to move people to flow, but if people wanted to just start with what you’ve laid out as Scrumban and use it instead of Scrum would it be ok to call it Scrumban” he said “sure.”
So Scrumban is either a process to move from Scrum to Kanban or a standalone method based on lean. This is considerably different than doing Scrum with a few Lean principles, it is basing an approach based on Lean.
None of Scrumban’s practices are immutable. You are either following Lean principles well or not. So Scrum’s immutable roles, events, artifacts and rules are not immutable in Scrum. This includes even foundattional ones such as the Product Owner. From Scrumban – “I also think that the Product Owner role is an especially egregious error that trivializes the problems of product planning, product design, and requirements analysis and hides them behind a black-box role that encompasses at least much complexity as the “development” part of the software creation process. The right answer to the wrong question is still the wrong answer i.e. software development is garbage-in-garbage-out.”
To be really clear, Scrumban is not Scrum with kanban practices in it. Nor is it Scrum without iterations. It is a process that stands on its own based on Lean.