[wojcech]

We need to unify this with actually hitting deadlines/making it economically viable, at least until basic income is a working model.

Maybe tie it so that every stage has a payout (20% ln start, 80% on finish or sth like it). First stage ist planning the project, in two stages: first has a fixed compensation based on headcount/"salary". This stage roughly estimates the scope and sets the upper and lower limit of budget. Based on this budget, the second stage does detailed planning, setting out as many sub stages as possible. This second planning stage is added on top of those stages, the total budget is divided between all stages and the first payout is done.

Like this, good planning is rewarded (teams with more stages get more frequent payouts) and there is still some pressure to deliver (payout) but even more to do good work (every stage depends on the previous ones to be doable quickly)

[dchuk]

This concept implies that it's possible to discover all possible scope before starting a project, which is almost always not the case on any project of relevant scale. This is waterfall.

The notion of "you'll get the rest of the money when the project is done" is toxic and dangerous, and implies that you can know what done means before you even start, and it's an objective and finite finish line you are approaching.

The reality is that you should be investing capital into resources over time to build towards a goal, and at regular intervals you should ask the question "are we done yet?". The answer should be based on what you have, not what's left in your backlog. Otherwise you'll descend into a groundhog day loop of checking boxes and completing tasks you came up with months ago without evaluating if what you already have built is good enough.

[wojcech]

> This concept implies that it's possible to discover all possible scope before starting a project, which is almost always not the case on any project of relevant scale. This is waterfall.

Difference would be that the team defines their own scope. But I see your point

> The notion of "you'll get the rest of the money when the project is done" is toxic and dangerous, and implies that you can know what done means before you even start, and it's an objective and finite finish line you are approaching.

This one I concede fully

[nradov]

In modern lean software product development with continuous delivery there is no longer a "project" as such with a defined finish. The team just pulls features from the backlog in a never-ending stream (perhaps with a planning cadence layered on top) until the product reaches the end of its lifecycle and the business cuts off program funding.