[williamdclt]

> development is an iterative process, and that I generally deliver work as soon as it's done

You're kinda arguing against yourself. I agree that dev is an iterative process and that estimating is a lost cause, but "deliver work as soon as it's done"? The whole point is that a "done" project doesn't exist. Deliver all the time (every day, every week at worst), iterate and stop the project when the client is happy with what they have

[mikekchar]

I think the key is that showing progress early and often lets the customer start to get a feel for how long the entire process is going to take. This is one of the reasons for XP's idea of trying to do "vertical" but narrow slices of the application. Each story you work on should work through as many layers of the application as you can manage.

It's easy to write stories that are "do the UI for X", and then "do the back end for X". But often the UI (at least the first cut) is easy to code and comes out quickly, giving the customer the impression that everything will be quick. Then you work on the back end and it goes a lot more slowly, leading to mistrust. Alternatively, working on really complicated things up front (while generally a good idea) can give the customer the impression that the project is stalled and that it's never going to finish.

When you are doing iterative development, I think the real art is in choosing your stories. It's difficult, but when done well it removes most of the political friction in development.

[jaggederest]

I really mean done as in "creates any positive change for the customer". Obviously if a file has syntax errors you don't push that to production. I usually do CI/CD really aggressively. Deliver as soon as the PR is approved or equivalent, assuming you have enough assurance in the form of test or qa. I would consider daily to be a little slow for my tastes.