Kanban - Some Open Questions?

So this topic has come up some here and there (I remember studying it a bit in my Supply Chain class) and I've been thinking about it and researching it a bit more and I have some open questions about it. So here you go:

Question #1 - Without a sprint commitment, what motivates the team?
The typical answer to this sounds like "The team is excited and aligned to the vision of the product owner so much that they will be motivated to see the team (and company) succeed". I agree...but without a commitment will they be as motivated? Let say for example, I join a gym that is $1 per month. If I go, then great, if not, then I've only lost a buck. Now let's say I join a gym that is $100 per month. If I don't go I'm wasting a lot of money and I'll either quit my membership or start going. The size of the commitment impacts how I act. With no commitment how will the team act?

Another way I started to think about this question was to go back to the roots of Kanban (manufacturing cars...learn more here). When manufacturing cars, a person will stand on assembly line and repeatedly perform the same task over and over again while the cars move down the assembly line. There is a key point here...each worker has a specified amount of time to perform very specific steps. That sounds very different than software development. Also, what motivates the assembly line worker will not necessarily motivate the software developer.

Question #2 - How can you understand your team's throughput when not every story is the same size?
Let's go back to another common question "How will you know if the team's performance is improving?" and the typically Kanban answer is that the amount of time per story will decrease thus increasing their throughput. But here is where I get confused...

Let's once again go back to the origin of Kanban building cars on an assembly line. The worker on an assembly line knows exactly what their task is and will always be and knows exactly how long it will take. That is not to say that improvements cannot be made to decrease the time it takes to perform a task, but rather that there is uniformity in the task. Compare this with software development where stories are introduced to the Kanban team. Some stories may be minor...and if a team gets a string of these stories in a row it will appear to the outside observer that the team is really performing since their throughput has increased. Now, suddenly they get some larger stories thrown in the mix and their throughput drops as the tackle these more difficult stories. Is the team performing poorly due to the non-uniform task size? Imagine if you will that same assembly line worker getting a 4 door family sedan and then a 2 door sports car, and then a 4 wheel drive truck and then the factory wonders why it takes they have a different throughput?

These are just some thoughts....Not sure if they are meaningful to the broader lean/kanban audience...so I welcome answers to the questions above! Please help! I definitely see Kanban's potential value and want to consider it more deeply, I'm just trying to answer a couple of questions, so go easy one me.