Scrumban

I would say no. When people talk about Scrumban, they often change Scrum and Kanban.  Scrum with Kanban doesn't change Scrum, keeping it simple and leverage Kanban practice to evolve the overall process.  No different then when you add XP or TDD practices on top of Scrum.  Keeping true to Scrum as a framework from which process evolves.  

Check out the Kanban Guide for Kanban Teams.

I have always viewed Scrumban as a version of Scrumbut. I see that as an attempt to modify both Scrum and Kanban to match the way that the organization works rather than using Scrum and Kanban in order to improve their operations.  Using Scrum with Kanban or Kanban with Scrum marries the benefits and powers of each to complement each other.  Much like @Eric Naiburg mentioned using XP or TDD to add benefits to the Scrum framework.

@Eric Naiburg, I didnt intend to imply that Scrum would be changed, but more on the lines of the practices of Kanban being implemented to enhance Scrum. for ex: more focus on flow, WIP, SLE and other metrics. I wasn't sure if Scrumban and Scrum with Kanban were the same though. Thanks for that clarification.

I also did a quick pass of the kanban guide and some of the key things like focus on continuous improvement, pull systems etc are all similar to Scrum. The only other difference I could see was the use of flow based metrics in the different events, like cycle time, lead time, throughput etc and also managing WIP in the different queues. If implemented and understood right, Scrum (standalone) is very similar.

I believe in practice some of us already follow these approaches with our teams. 

Scrumban was formulated as a means of gradually replacing the Scrum framework with an increasingly pull-based way of working. If Scrum is implemented with a Kanban strategy, however, many of the original goals of Scrumban can be achieved.

@SteveVb also check out the work of Yuval Yeret https://www.scrum.org/resources/blog?uid=244459 

It seems like "Scrumban" is a very ambiguous term. My understandings of it differ greatly from Daniel Wilhite and Ian Mitchell's statements. When I've heard of Scrumban, I've typically heard it as applying Kanban to the Scrum process - Kanban boards with columns for states, WIP limits, and queue-based Sprint and Product backlogs (work always comes from the top).

Kanban just means "signboard". The idea of Kanban as a process is much newer than Kanban as a tool in lean manufacturing to make the progress visible. The fact that you measure certain things, such as throughput, work item aging, cycle time and lead time doesn't come from Kanban. Kanban is just the visualization that makes these things apparent. There's also this idea of the Kanban Methodology and Professional Scrum with Kanban that builds a process framework around Scrum and/or Kanban that calls for these particular measurements and metrics. My understanding of Scrumban has always been that it takes the visualization aspects that are truly Kanban, and not the process framework or metrics.

The first time I’ve heard of the term was when I was reading PMI Agile Practice Standard and this is how they define this hybrid approach: 

“Scrumban is an agile approach originally designed as a way to transition from Scrum to Kanban. As additional agile 

frameworks and methodologies emerged, it became an evolving hybrid framework in and of itself where teams use 

Scrum as a framework and Kanban for process improvement.

In Scrumban, the work is organized into small “sprints” and leverages the use of kanban boards to visualize and 

monitor the work. The stories are placed on the kanban board and the team manages its work by using work-in-

progress limits. Daily meetings are held to maintain the collaboration between the team and to remove impediments. 

A planning trigger is set in place for the team to know when to plan next, typically when the work-in-progress level is 

lower than a predetermined limit. There are no predefined roles in Scrumban—the team retains their current roles.”

They clearly mention that Scrum is used as a framework and Kanban is for process improvement which is somehow in line with what Professional Scrum with Kanban is about as well unless I am missing something.