If you look at Kanban specifically, you can tell if it's been implemented well because it's not just affecting the team. It's a tool to improve the entire value stream.
Even that is a bastardized version when compared to what Toyota developed. The reality is software engineers are not factory production line workers. Also, kanban negates the fact that cars are completely spec'd out (aka waterfall) by the time a car is ready to be built on a production line.
Yes, and a vast amount of the design detail that goes into car design is to make building it easier.
You're right that software engineers aren't factory production line workers, but I'm not sure it actually matters. The only detail I can see relevant to whether kanban can work in is the distribution of how long each piece of work takes, and while you'd expect the distributions to be different between "bolt lump A onto tab B" and "add feature X to website Y", I don't think they'd be different enough to completely break the queueing model. I'm not sure that it matters that each piece of work through the team is unique versus the completely repeatable part assembly stereotype of factory work.
The main issue I see with kanban as a software development idiom is that in every place I've worked, supply cannot be effectively constrained, except artificially, at the gate into the team. There is always more work to do than time to do it in. Now part of that is a cultural problem to do with politics and the place of the CIO (or equivalent) in a typical company, but it definitely feels like kanban needs to be driven from outside the tech org to work well.
