I don't like this phrasing. I don't really even like the idea. I think this is the first one that doesn't have a reference.
The problem I have is that the incentives and motivations for developers and customers are going to be different. Excluding developer tools - I'm gonna go for 'always'.
This one also uses REALLY sloppy language for "developer". It says that the developer wants to maximize profit. Well... no. That's generally not a developer perspective. Business, sure - developer... not so much.
The example in the book is the customer wanting 3 features by a specific date. The development team targets all 3 features and delivers late (and probably buggy since they'll try to hit the date, and buggy since this book thinks low quality code is the only non-outrageous way to write code)...
Anyway - That's not aligned with the customer that would have been fine with just 2 features by that date. Again - Customers don't know what they need. They'll want the world, ya gotta help them figure out what it is they need.
So, yes.. "align incentives" for the developers to focus on delivering the things the customer will get the most value from.
How do you do that?
Principle 8 - Talk to your customer! Get the priority! You say, X, Y, and Z are all absolutely required. If I could give you one tomorrow, which one would you want? If I could only do part of that one tomorrow, what part would you want?
Do that one.
Ask those questions again.
Do that next one.
Repeat.
As each of these features are completed, give them to the user. It might be a couple weeks instead of tomorrow; but put it in the users hands. Not as a prototype or to get customer feedback - You'd had better been getting customer feedback the entire process, but as a finished deliverable. Deliver that functionality to the user.
Do it again.
Eventually the user will have a bunch of functionaltiy and may realize they don't actually need all 3; the parts of the other things covers what they need.
Users ask for the world; we need to help them discover what's actually important to them. We do that by communicating and helping them focus on the most important thing.
This isn't "aligning incentives" it's iterative development. We want to "align" developers and customers around the most important piece of work; and get that done. Then do it again.
So... Phrasing sucks; but the idea behind it of delivering small units of functionality is good.
The book suggests monetary rewards and ... penalties... Again; this is clealy sloppy use of "developer". If you're doing monetary rewards and penalties to your developers - you're a terrible manager and should be fired and never placed in a management role again.