"Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)
Thank you for the clarification, but I am afraid you lost me at this part:
> "Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)
What is "in flight stuff" and "traffic limits?" Are you saying strict Kanban minimizes the number of tasks that are in progress in order to prevent overloading the team i.e., there is an upper limit set to curtail the amount of simultaneous tasks?
Right, Kanban comes from "just in time" factory needs where you've got scarce supplies that feed scarce resources (particular stations). It started on physical index cards representing "parts" that needed to flow through stations. Each station would pull cards representing the parts they need, but weren't allowed to pull more than they could work with at a time. When "parts" run out new ones need to be ordered. Putting it on a central board was all about finding: what parts are needed where, visualizing which ones run out first, and visualizing where the bottlenecks are. (A lot the parts are stuck waiting on a particular station to pull them and maybe that station is blocked for some reason.) At any point if there is too much in any single column "something is wrong". You are missing a column or work isn't flowing right.
Not all the factory needs apply to Software Kanban, but it's still a useful analogy in various ways. Plus not all software for working with Kanban style boards is great at some of things "Physical Kanban" is better at. (Some of the best times I've worked in Kanban board software was eschewed altogether and it was done in index cards on a whiteboard. There is something to be said about physically moving cards around that the software boards don't quite capture.) While the "raw parts" in Software Kanban are generally considered to "backlog items" (features/stories) and are plentiful rather than scarce (and this is one place where the analogy to factory operations kind of breaks down a little bit), in "strict" Kanban each column or "station" is expected to have somewhat strict limits to keep from overloading the team. Only so many tasks in progress in development at once (often capped at one per developer), only so many tasks in progress in QA testing at once (often capped at one per QA person), etc. You can visualize bottlenecks: if there are too many tasks in Development and not enough for QA, maybe the stories are too big for a steady cadence (Development is your bottleneck); if there are too many tasks in QA instead maybe QA is your bottleneck and you need more QA resources. If you need to scroll a column there's probably a bottleneck to fix (or a column/"station" you are missing).
Setting bandwidth limits, finding your "stations" in your column designs to help find and visualize your bottlenecks, is a lot of the art of Kanban. That and Kanban's focus on "pull" rather than "push" are big differences between Kanban done right and Scrum.
"Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)