Hacker News Reader

Comment by logicalmonster | Hacker News Reader

You might end up coincidentally liking some parts of these software design methodologies like Kanban, but they generally aren't intentionally implemented to maximize developer happiness. For me, even the name "sprint" just instantly pressures me to feel rushed in my work and I hate everything about this religion.

These methodologies are designed to be a "good enough" default way for non-technical managers to organize and manage projects in a domain they don't really understand.

Imagine how confusing going to the mechanic is when you don't really understand cars. You're constantly left wondering if he's bull-shitting you about the cost and effort involved in a repair and if any progress is being made and work is actually being performed. So I get why this needs to exist, but I understand that it's not about benefiting the developer.

View on HN

As a customer of this auto shop, I insist that there will now be mandatory 15-minute standup meetings every morning where the mechanics must provide me detailed updates on what exactly they did the previous workday and what they plan to accomplish today. I better hear more than just "worked on car brakes" - I want specifics!

We will also have two-week sprints with clear repair commitments that get tracked on a big visual board. If everything isn't completed by the end of the sprint, the mechanics will need to stay late and explain to me why not during an excruciating one-hour retrospective meeting. I don't care if these nonstop status reports, sprint planning sessions, standups and retrospectives frantically disrupt the mechanics' workflow. As the customer, I deserve to know what work is happening to my car at all times! Sure, my neurotic Agile mandates may cut actual wrench time in half while accomplishing nothing. But I can't blindly trust these mechanics' expertise - they need to recognize this agonizing process is for their own good, even if they hate it. I'm the customer so we'll do Agile repairs my way, no matter how much it impedes progress!

Some of the irony of this is that the actual PM should be more like a mechanic shop manager rather than the customer. One of our current issues is that we got a new PM who is, well, as you explained above. The hardest part is for them to even write sensical tickets. They can't figure out what is BE or FE work so their tickets mix multiple items while the company bans sub-tasks that devs make.

All that said, I'm 80% sure the comment you made about sprint making it feel rushed is directly noted in Basecamp's Shape Up, which honestly is a great way to run small projects where results are more important than metrics.

    For me, even the name "sprint" just instantly 
    pressures me to feel rushed in my work and I 
    hate everything about this religion.

While I think Scrum is a small step forward relative to the chaotic nightmares I've generally experienced in this industry, I wholeheartedly agree with this criticism of the term.

"Sprint" makes zero sense as a term. By sheer definition, in the real world you cannot sprint all the time. In fact you can only sprint for a very short time. Perhaps less than 1% of your waking hours.

And yet, in agile, we are supposed to be "sprinting" all of the damn time. There is only sprinting. There is nothing else but the sprint.

Dumb and probably harmful choice of terminology.

Reply on news.ycombinator.com