"We need smaller deliverables so that we can validate each iteration with the client! Instead of doing the whole batch, let's try a minimum viable unit of work first!"
And then the cook made a single unit of French fries. Like, a single stick. It took about 10 minutes, or about 95% of the time it would take to fry a whole portion.

True, but I like the small tickets, it's more administration indeed but you have many times feeling of completion

@retoor althougt the idea is sound in moderation, there is such a thing as over-partitioning.
Imagine you had to cook 50Kg of raw rice.
This is too much for a single cooking pot. So you divide the load into smaller deliverables.
Great. Unless you budget for 50 thousand pots, each to cook a single grain. The overhead of setting each one up and joining the final product will take longer than it took to plant and grow the rice.
That is the sort of over-reduction of deliverables that I'm dealing with.
Bloody buzzword-only management.

Comparing software deliverables to French fries is stupid.

@JsonBoa I understood the first time :)

@superdupernova If it takes 10 minutes to cook the Frensh fries, something is already wrong from the start.

Here they can fry them in less than that.

Pre-cook for 5 minutes at 160°C, cool them down to room temp. (These steps are all pre-cooking and prepping)

Next 1-2 minutes to make them golden brown at 180°C = Perfect Belgian fries.

In Germany we say that you can’t deliver the baby faster by hiring multiple pregnant women.

@retoor I agree, though $work really killed that for me.

Tickets at $work have lots of dance steps:
• Move ticket into sprint, set to in-progress, set “dev resource”
• Negotiate release date w/ QA
• Read ticket; talk with stakeholders for details
• Add est. story points
• Do the work
• Revisit with stakeholders
• Write specs
• Manually start CI
• Spec+CI iteration as needed
• Copy CI results to Jira
• Open PR; do self code review
• Ask in Slack for a code reviewer; babysit
• Write detailed steps for QA, w/ sample data, screenshots, expected results, gotchas
• Write detailed application security + data security notes in Jira
• Write up technical implementation summary
• Find avail. testing server and claim it in Atlassian; ask QA to approve server
• Deploy to testing server; test again; release server
• Babysit ticket through QA
• Update branch as it stales
• Get release approvals
• Update Atl. release page
• Notify sysops of migrations
• Ensure ticket isn’t lost during QA / release building

I forgot to add:
• Schedule a UAT demo with the product team

@Lensflare that's not only Germany

@Root quite some steps. We had refining sessions to work out details for every ticket in sprint, so per smol ticket, you do not really communicate with anyone. Administration, code, go

@Root Damn, you create hole new servers for every ticket you finish ?

Looks like baking one single fry at the time and changing the oil between each one no ?

@Grumm Server is already created; this is just deploying new code on top of it. (And recreating the data from daily sanitized prod data)

But yes. This whole dance routine takes forever.