Is Scrumban the same as Scrum with Kanban?

I always just thought of 'Scrumban' to be just a shorthand or slang of 'Scrum with Kanban'. 

I look at it as a way to ensure that the team is applying empiricism to their continuous flow process. If the team is not looking back on past experiences and using it to drive future behavior and process improvements then they're missing out. Taking advantage of the framework that Scrum offers is one way to do this. 

You can do Kanban and still inspect and adapt the process without any of the Scrum ceremonies. 

And yes, throughput can be measured in whatever increment the team finds most useful. Throughput referring to the departure rate of work from the process. 

I have always considered Scrumban to be a mixed up attempt at trying to do something agile using a board and sprints.  While Scrum with Kanban is a more definitive attempt at using Kanban practices within the Scrum Framework.  The reason for my interpretation is that Scrumban was used much in the same way that Scrumbut or Scrummerfall was used in the context of discussions I have been involved.  But given the technology industry's fondness for acronyms, I can see it the way that two of you describe it.

10 years ago the contention was that Scrumban ought to be seen as a journey towards pull, or prioritization on demand.

http://leansoftwareengineering.com/ksse/scrum-ban/

10 years ago the contention was that Scrumban ought to be seen as a journey towards pull, or prioritization on demand.

@Ian Mitchell, Per my understanding, both Scrum and kanban are pull systems and in the case of Scrum we can prioritize some work if it does not endanger the Sprint Goal or if the situation is such, then the Sprint could be cancelled.

I don't understand what problem was trying to be solved by calling something Scrumban, when kanban on its own is sufficient. It feels like an attempt at using Kanban but the word "Scrum" should also exist.

My understanding of Scrumban was to follow the cadence and ceremonies of Scrum, but the day-day process is performed in a Kanban style. Or rather, take Kanban but inject team planning and continuous improvement at regular intervals.

All work is relatively the same size and can be worked on by anyone. Sprint planning exists to determine how many stories to include in the Sprint. Team attempts to get them all done and Review the Sprint and perform a Retro when the Sprint ends. The difference being the Kanban style applying to the day to day. The team focuses on swarming Right to Left and maintain continuous flow by pulling into in progress the next in line piece of work.

Typically the type of work would dictate this process choice. Something like a team of designers working on animations would want to perform an action within a day and see more of them performed through the Sprint but then review the completed work at sprint end to determine what they do first in the next sprint, while improving their working processes to best support their demands.

There are a few things that tend to get conflated when talking about Kanban.

First, you have kanban. Kanban is a technique that was popularized by Toyota as part of the Toyota Production System, but the underlying ideas predate that by years. It's designed to support just-in-time manufacturing by being a visual indicator of stock - it ensures that producers have a signal when new stock is needed so they can produce it. It helps to enable a continuous flow.

Then, you have The Kanban Method that was popularized by (as far as I can tell) David J. Anderson. This is a set of principles and practices, not unlike Scrum, that describe an approach for implementing a lean product development process. There are a few books written by Anderson that detail his philosophy and approach.

And you have Scrumban. I don't think that this is a well defined concept, but my impression is that it takes the fundamental principle of visualization and adds it to Scrum. It uses cards and boards to represent Product Backlog items and Sprint Backlog items and what state they are in a workflow. You may add some work-in-progress limits to columns on boards and track a few basic measures or metrics, but it's otherwise Scrum with boards.

You also have what Scrum.org calls Professional Scrum with Kanban. This is a robust definition of flow and workflows, flow metrics (work in progress, cycle time, work item age, throughput) and ways of visualizing this data, work in progress limits, and how all of these provide inputs to the existing Scrum processes. I would consider this a way to enhance Scrum with more techniques from the lean community.

I would not consider Scrumban to be the same as (Professional) Scrum with Kanban.

My advice is to:

• read the article on Scrumban by Corey Ladas which I linked to,
• bear in mind that the ideas are 10 years old,
• allow for the possibility that the significance of a Sprint Goal might not have been appreciated, and
• remember that the Scrum Guide itself has changed over this time

As it's clear in this thread, there is no single definition of Scrumban because it's not an official framework. For the teams that I work with, I have a few that use Scrumban and in our organization it is basically Scrum without the Sprint timebox. All other ceremonies values, and roles are utilized but the teams use a Kanban board and don't use the Sprint Timebox. 

For obvious reasons, we (coaches on site) try to encourage teams to pick either Scrum or Kanban based off their products and environment and only use Scrumban when it makes the most sense. The reason is because it's basically a hybrid framework that people can pick and choose what they want and how they want it so it creates a lot of headache and confusion across teams. 

it is basically Scrum without the Sprint timebox.

@Curtis Slough, I have to respectfully disagree that it just isn't Scrum. It maybe Scrumbut, but definitely not Scrum. Why add the word Scrum even? How would the outcomes be different if there were no roles (from Scrum) and if you just practiced Kanban using a cross-functional team?

These are the first 3 (and often considered) key principles of Kanban.

1. Start with what you do now

2. Agree to pursue incremental, evolutionary change

3. Respect the current process, roles, responsibilities & titles

4. Encourage acts of leadership at all levels

Why can't teams that are not sure if they can practice Scrum, start with Kanban and these 3 rules? Keeping the above in mind, can they also do the below?

1. Visualize the workflow

2. Limit WIP

3. Manage flow (of value)

4. Make Process Policies Explicit

5. Improve Collaboratively

If yes, they would be practicing Kanban.

My annoyance with the term Scrumban is because of how it convolutes the understanding of both Scrum and Kanban, how it is being taught by the so called "agile coaches" as the solution when people don't want something in Scrum.

Often taught as Scrumban = Scrum + Kanban, BUT... no need for a timebox, Daily Standup is mandatory (cos that's how we do Agile), other scrum events as needed (we don't need a retrospective, we don't need a review etc).

Why not keep it simple and just practice Kanban?

First off, you missed a very important part of my comment, let me fix it for you:

... in our organization it is basically Scrum without the Sprint timebox.

This was NOT a declaration of what Scrumban is or should be. This was an example of what teams in the organization that I work for utilize. 

I have to respectfully disagree that it just isn't Scrum. It maybe Scrumbut, but definitely not Scrum.

Um..... Yeah I agree...... I never called it Scrum, so.....?

The reason it is used over just Kanban here is because it provides more of a structure than Kanban does. The teams use all of the roles and events except the Sprint so that is why we use "SCRUMban" because we literally use every element of Scrum except the sprint. The only time a team uses this is when they have tried and failed with using Scrum or Kanban. The decision is not based on "what teams don't want to do" it is based on what doesn't work with the team and their product. 

Call it Scrumbut if you want but we call it scrumban because we utilize elements from both frameworks. Scrumbut, to me, is more along the lines of a team following the Scrum framework but decides not to do Retros or Reviews and do not incorporate anything else in place of those. Scrumban takes from 2 frameworks and forms a hybrid approach to make it work for an individual team, that is why we (in my organization) call it "scrumban" and not "scrumbut".

so called "agile coaches" 

I have the privilege of being an Agile Coach, I don't label myself that, it is a title I was given. My goal is to help teams be the best they can be. I don't ram stuff down their throats, I don't demand control either. My goal is to be a support group for them if and when at all possible and provide some suggestions along the way.

There are many terrible coaches out there that work for heavy handed consulting firms that come in and demand companies follow a specific process and structure. There are also great coaches out there that really want to help teams be the best they can be. The same can be said of Scrum Masters and Product Owners so maybe before you loop all agile coaches into the same box, take a minute to recognize that fact. 

My experience tells me that it comes to Scrumban when the team doesn't understand Scrum as a framework, and hence starts experimenting.
Honestly, I almost did not see the Scrum implementation according to Scrum framework and scrum guide. 

Just a visibility of Scrum ignoring the fundamental principles of Scrum that make it work properly. That's why teams often use/call their approach as Scrum like something or Scrumban, or Adapted Scrum or whatever.

And the main point: Scrum is a framework that works well for the endeavours that have a high level of uncertainty (about the result and technologies to use, etc.). That's why we have short sprints - to experiment with solution. 

Scrum was introduced about 40 years ago. Comparing the nowadays level of uncertainty for the software to the 80-th it is obvious that today it is hard to find a real project with a high level of uncertainty.

Bank app/fintech, E-commerce, healthcare, taxi, delivery, CRM, LMS and many other domains - do we have a real uncertainty there, or we just can hire a core team that has a wide experience in the required domain?

I believe that it is much rational to find and use the experienced in the needed field team than hire guys, that understand Scrum poorly (very often) and that don't understand the field.

I would follow the second option.