You think that it is how it's supposed to work, but that's not really how it works. When a bottleneck presents itself everyone gets to work around it as it is not fixable by them! (Or the fixes are deemed either or of scope out to time consuming, so you're directly even prevented trying at it.)

Generally you cannot fix things you do not have control over. Kanban is meant to have a process person fix the bad bottlenecks - not the developers, not the managers - and said person is supposed to have the clout to pull it off. I've never seen Kanban implemented properly.

As for the example - if testers are not keeping up, either you hire more or enhance testing methodology. Throwing developers at it slows down development moving the bottleneck. (Of course, throwing some developers to provide better testing methodology, testable components or automation would be a proper fix.)

well, any type of process will fail in a dysfunctional organization :). And you can't (well, shouldn't) arbitrarily implement a specific process without thinking through the fit for your organization. Just buying a license to a Kanban tool isn't enough :).

The example you gave is a good one - devs spend their time making improvements to to code or the test automation to make the testing more effective, if testing is the bottleneck to delivering finished features. Throwing more code/features over the wall when that code isn't actually being tested isn't real progress.

In principle, the manager/lead would tweak guidance until the most expensive resource (dev engineers) are the actual bottleneck. I guess of course teams/companies that care less about quality might just tell the testers to test less thoroughly in order to get their work items through the system faster, but at least it's a conscious decision.

I've worked for teams where they literally close every testing ticket once the code is pushed to production regardless whether the testing has been done. 'tested in production' - that's one way to keep up I guess...

It's a great way to have an unfixable mountain of tech debt.

See, Kanban only works when the focus is on quality. It's the main secondary premise of the original Toyota approach of Lean which spawned Kanban. Note that it starts with minimizing waste (in programming, tree breakage or waiting on tests) and secondly minimizing overloads. The philosophy is kaizen, continuous improvement. Sacrificing quality is not an improvement, Toyota itself started by breaking process into quality assured steps to fight waste due to rework.

Otherwise anyone can push undone paper tickets over the wall and that's not the point.