Hacker News Reader

Comment by scuff3d | Hacker News Reader

My job wants us to plan sprints 12 weeks in advance. That includes decomposing epics into stories with full descriptions and acceptance criteria, which anyone who's actually worked on an agile team knows is a complete waste of time. By the time imyou get 6 weeks in things will have changed too much.

By far the most useful thing AI had done for me is let me plow through all that in a fraction of the time I would have before. They're spending a ton of money to make employees more efficient at the pointless bullshit they themselves put in our way.

And before some scrum master shows up and tells me how important stories are, I'm not arguing against planning. I am arguing against pointlessly over planning to make a bunch of suits happy when teams aren't given the kind of time to actually plan that far in advance.

View on HN

I've tried explaining this to people till I'm blue in the face. It's simply unreasonable to plan specific tickets out that far. We simply don't know what we don't know. And that assumes business priorities will not change and the project requirements will not change (two things that almost always happen). Additionally, the mindset that we can embark on a multi-week/month project and stop/start it at a whim.

Ditto. In my experience it comes from our customer more then internally. They want all the risk reduction and stability provided by the old "waterfall" methods, but with the flexibility and speed of agile. But of course those two things don't mix. You need months if not years to plan a project the way they use to. We can't cram that amount of planning into a week.

Worse yet, once all those stories are made, they don't want us creating more. It takes a damn review board to get anything changed.

This is why I always champion technical leadership. Many, many people seem to think this is unnecessary, but I think it's common sense. The layman might see building software like building a house. We know basically all the components of the house, we know we need to lay the foundation before raising walls and installing a roof. Software development is nothing like this. You can add a roof before the walls, you can dig an entire basement before providing any method of descending into it from the ground floor.

In my company we do have predominantly "technical" leadership, as in almost everyone has an engineering background, but we still run into problems. For software folks that's mainly because leadership either tends to come from other non-software domains (EE and ME mostly), or it tends to be people who honestly weren't very good at the actual engineering side of things to begin with.

Yeah... I think you've hit the nail on the head. Technical is probably too broad of a description. It's never made sense to me the amount of people leading software development in some capacity that have never developed any software, let alone any within the domain they "lead".

I've seen some companies expecting 2x output from Devs because they now get Cusor licence

Reply on news.ycombinator.com