[laurent92]

z) Customers are gonna complain anyway and ask for more, so better make 80% of the feature and see what they focus on.

z’) If we deliver 20% of the wrong feature, the customers are going to say it and we can reorient before we make the other 50%. #Agile

I’m not very satisfied either but the history of programming is riddled with us building overengineered solution to the wrong problem.

[michaelcampbell]

My background (and experience) might be different than many here, but I've worked in dev orgs that specifically did the every-6-months big-bang release to a customer, with the BigDesignUpFront, waterfall, and all that. There were some wins here:

* Customers signed off on requirements; they may not have liked them, but they knew what was coming. And when.

* The dev org got to have the (IMO important) psychological journey of discovery, creation, testing, "oh shit", last minute fixing, last second covering up, and the final human release of... releasing. Big celebration. Yay, we did it. My last couple positions have been SAAS stuff where we "release" tiny little things multiple times a week; sometimes multiple times a day. Honestly, it's a grind. There's no "big win". It's akin to "death by 1000 cuts". You don't have the big wins or the big losses, but you get ground down by the never ending stream of small stuff. Writing an app is like putting yet another pat of snow on the snowball.

I get where agile is coming from, but a lot of times it fails to recognize that sometimes, people actually DO want to be surprised with big things, even if they're not 100% positive. And sometimes, customers DO want to have the vendor "Just deal with it and leave me alone - I can't be bothered multiple times a month (or week!) to look at your teeny little new thing. SHOW ME THE FEATURE WHEN IT'S DONE." They WANT that ability to gripe all at once in the end, and not be part of the "steering committee - what am I paying you for if I have to dictate everything?"

I'm being hyperbolic here of course, but I've seen versions of this play out numerous times.

[wereHamster]

Not celebrating is a cultural issue. Even if you ship a thousand new things a week, you can still take time to celebrate those. It's your (or your team's) choice not to.

One good example is Linear. The product improves day by day, but they also publish a regular (weekly) summary of the changes. And for me as a user it's a delight to read through them. https://linear.app/changelog

[gmfawcett]

I don't think a client-facing changelog tells us much at all about how the dev-team celebrates.

Calling it a cultural issue seems off. Perhaps in some cases it is. But if the process truly is a grind, then the only target left to celebrate might be a proxy metric that the devs don't relate to. (Congrats on staying within 0.5 sigma of our mean time to deliver this week, let's have a pizza.)

[maccard]

Celebrating doesn't have to be a reward, and assuming that celebrating a release involves a material reward is certainly cultural. To me, the important part of celebrating a release/milestone is pausing and reflecting on what has changed. That only needs to be a small nod.

[creakingstairs]

> There's no "big win".

Even though you are shipping piece by piece, don't you still have a "big win" that those small pieces make up to be to celebrate? For example, my old team had to deliver MFA. This was broken up and was "released" continuously. We celebrated when the whole feature was "done".