A case from fintech when you built a car, but the business just wanted to honk the horn louder (or the story of one “slavery” from our lead frontend developer).

In Intspirit we often chat about strategy, values and planning. But real adrenaline is delivered by exactly those who really write the code.

We have a frontend dev working via outstaff in a huge fintech company. He has a superpower: a couple times a year the leadership "gifts" him to other dev teams. This is such a corporate Fort Boyard, where you need to find keys, not to burn out and carry the treasures away.

He went through this 5 times. And here we go again.

Situation: end of the 2025 year. Adjacent project of two teams. Two systems analysts, lead from the other team, 3 frontend devs, QA and one test stand, which is occupied more often than the office coffee machine in the mornings.

Processes: pure Agile, no compromises.

Setup in Jira: tasks with name, without anything else.

Acceptance criteria: written on the knee in breaks between "developed - reworked".

Result: several times rewrote almost from scratch. Why? Because "we did exactly as said", but the business "wasn't thrilled enough".

Cherry on the cake 2 days before the code freeze:

He (writes in chat, with medicine dropper filled with coffee): - Good morning! Maybe a short call? Otherwise I'll push the task now, designer with tester will look, two analysts will approve, and then manager will throw that everything should be different...

Lead (standing back to the fire): - Yeah overall normal, this wasn't in the requirements, but we tried to use - it's inconvenient hehe. We live in Agile, feedback is more important than the plan!

And boom - it ignited, not like a lightbulb over the head, but like a crypto farm processor. After all, the deadline is out, need to hit quarterly goal, code freeze soon, feedback arrives at the last moment.

First thought was: - Well this is classic. Working in Agile in fintech - this is like building a car, where first you need to develop a skate, then scooter, then e-scooter, then cart with rail cart, then buggy and finally the car itself. But we deliver the value fast!

But the developer corrected us, because developers see the world better than us, managers:

Not quite. Making a car in Agile in our team is make a skate.

Understand that skate doesn't hold asphalt, roll back to roller skates.

Make a cart (because need to carry potatoes, urgently and so that others can maintain later).

Along the way suddenly invent a rail cart.

Assemble the car.

High-five for 5 minutes.

Then spend a couple months tuning: air conditioner, power steering, nitrous injection system and Alcantara interior. Because business tried to ride without AC and now their windows are fogging, so let's quickly finish in the next sprint.

You know, what's the most interesting? He seems right.

A takeaway for those who manage products: flexible methodology - this is not about absence of requirements. This is about the ability to timely say: “Stop, guys. A car is a car. Let's not confuse sprints with test-drive of the client's concept-car.”

Tasks with full details to everyone!