I think “thou shalt care” should be the rule in every great team, no matter which approach you choose to deal with software development or project management.

But the truth is the more authority you deal among team the more you’re fragile to those who don’t care. It looks like I choose very flexible approaches and tend to work people who care for the same reasons.

If one’s goal is to organize the process in a way which squeezes most out of the team it just can’t succeed. It doesn’t really matter if we discuss Scrum, Kanban or one of more structured approach. Limits in Kanban are not for making people run faster. And cutting them beyond reasonable level results in decreased productivity.

By the way if limits become a pain in the neck and you face bottlenecks every week or so it’s likely that limits are broken, not the team.

A note on your “I wanted to write engineer”-comment:
I’ve actually seen Kanban (and partly Scrum) crash and burn more often because project managers have broken the WIP limits and impeded the flow, in their search for squeezing out the last drops of imagined effectivity by parallelizing the team – thus destroying the actual effectivity by paralyzing the team.

Yes, Kanban doesn’t enforce much of structure on team. But on the other hand it doesn’t forbids you to build the structure nevertheless. You can’t look at Kanban only through things which Kanban prescribes. It doesn’t say a word about software development practices. But so does Scrum.

Consider this example: you work with a bunch of crappy but disciplined engineers. I mean they produce low quality code but they don’t tend to ignore the rules. Now, take this team and implement there Scrum by the book. What you’re going to get is structured way of delivering crap.

Yes, you can do more, invite good engineering practices etc. But Scrum doesn’t prescribe it. The same is with Kanban. Kanban alone is not enough so you basically have to base on other techniques practices as well.

But coming back to the point – your 28x engineer could blow the agile process up if he didn’t follow a few rules which are agreed among the team. It doesn’t really matter if he ignored Kanban board, time-boxing or planning meetings. As long as his work was completely unpredictable and no one else could say what is he doing right now without getting the guy out of his flow it wouldn’t work well.

On the other hand the guy should work better in less structured approaches, so for example as long as he would keep the Kanban board up to date he shouldn’t be much of trouble in Kanban team. And he would definitely appreciate huge freedom he would get.

It works as general rule by the way. If you don’t break the rules but you use as much freedom as you have no one should complain. If you break rules by default you’re considered as prima donna and treated like a black sheep.

I once worked with an engineer who claimed to be 28x faster than the average engineer (at least when he was younger). I have no idea if he had a formal method of measurement, but I would tend to believe him after watching him work; best as a lone wolf, no systems or structure to tie him down, and no team to hold him back. Pure natural talent, skill, and experience propelled him forward in way that was seldom matched. Of course, it was virtually impossible to get transparency into how he was doing or how he did it, but when he said it would be done, it was.

It is pretty tough to scale a business based on the 28x’ers. The bulk of us range from mediocre to above average. Implementations of agile as “kanban” tend to strip away many of the things that make the bulk of engineers produce predictable speed and quality of code. If you strip the structure away, expect most teams to drift into a bad place over time.