Why Scrum is stressing you out

This guy has clearly never worked waterfall, the progress bar doesn't look at all like in the graph. Instead, there are even more milestones throughout the project. Granted, they are usually spread out further than every 2 weeks, there is no such thing as just one final deadline where you can slack the first half of the project.

Month 1: Specifications need to be frozen, because month 2 all the test plans need to written, so that month 3 all the test cases can be implemented. Then month 4 all code should be written and month 5 we put everything together to test it. Hoping that what you wrote down half a year ago is still relevant and the most important thing to work at now. Add a complex web of dependencies to other teams on a gigantic gantt-chart with fixed dates and you will have deliveries regularly anyway.

Usually, by month 2 you are already overdue on the first milestone. The time plan is not going to shift because of it. Meaning you now have even less time to meet the second deadline, obviously it will be missed, repeat throughout the remaining milestones, resulting in constant stress throughout the project.

That's not to say that the graph doesn't exist, its just not called waterfall. It's longer deadlines with more autonomy between.

I have had consequences for not cranking out work fast enough. Usually PIP or PIP-larping processes are run. I then resign find another gig.

I learned scrum back in college and I hated it so much. I remember we had to meet 2-3 times a weak. And for each meeting we had to present something, with slides as well. We spend more time thinking about usercase than writing the code. I guess that's good in its own way but honestly I don't have such superpower to report something new every meeting. In fact most of my meeting back then were "I am still coding X" and that was it, then the scrum master or the leader would talk about big picture over again.

> do estimation the same exact way, but rather than arbitrary deadlines,

The core problem with that is that effort - consciously or not - gets immediately turned into (start day + estimate) => deadline which only works when you consider spherical cows, not accounting for the hard true practical fact that reality is messy.

And it is quite messy, by the very nature of the work which is to do something that has not been done before (otherwise by the very nature of software you'd just reuse it) and thus carries unknown unknowns. Everyone has experienced this "one-line fix, should be done tomorrow" that turns into a bind-mending multi-week hunt down the rabbit hole; replace "fix" with "feature" at your discretion; replace rabbit hole with "that very urgent task preempting anything else".

The second-order problem is that deadlines are used to schedule higher level dependencies between teams, all the way up to product, and possibly customers, and then it becomes the coupling interface and everything falls apart when there's a delay that inevitably trickles up with rippling consequences, because the system is not designed to handle such a failure mode, having this deadline dependency as its core interface between all the parts.

If you're not convinced of that, "follow the money": the consistent metric across the software industry to evaluate an employee's performance boils down to "deliver on time". Three months down the road, the rational explanation to delays of mandatory rabbit holes and very legit preempting tasks is forgotten, even when acknowledged by management. You're told to factor all that in, but estimating unknown unknowns is by definition impossible (best case you go statistical, with deadly outliers around the corner, which amounts to say it's a bet). Experience reduces these unknowns but they're still around, everywhere. Overall, you tried telling the hard truth with absolute candor were left helpless when it backfired.

Ultimately, whatever the process, the stark reality is that to get shit done you have to take part in the make-believe dance and lie - white lies, because soon enough one realises that the other kind of lies also backfires very quickly - in a way that still communicates some form of deeper truth: "progress is being made, it'll be done (when it's done)". Inflate some numbers, tune wording when reporting, steal time by bleeding some for task X (reported or skunkworks) into task Y. All the reporting meetings and documents entirely become smoke and mirrors, but are somehow important as they're oil to the whole machinery. Two parallel universes emerge and graciously evolve in parallel.

This sleigh of hand is the missing buffer catering for the lack of acknowledgment that producing software is entirely different in nature than producing hardware in a factory. It is in essence more of a creative act, albeit a strangely misleading one because of its technical component. Lots would be amazed as to how much closer it is to advanced drawing or musical composition than it is to more "material world" engineering (although the rigorous process of the latter certainly helps for technical aspects), and taking classes of the former would probably do a lot of good.

Work queues are themselves an issue. Instead you should have ways of documenting things that need doing that is adaptive. For example a groomed page about all the PDF bugs > 56 Jira tickers going back 10 years, some will take a day work to even fathom. It is a big time waste. For customer communication have case tickets. But a JIRA ticket is like body fat. You burn calories just to maintain it.