Agile has fundamental structural problems which, combined with office politics which it can destructively amplify, make it an inevitable nightmare to work in.
Is AI being used to moderate comments now on HN? I ask because I don’t find this comment to be particularly moderation-worthy according to most modern standards of flamebait.
Yeah it wasn't my finest moment but I didn't think it was very out of place. I think moderation here is 'flag based' - ie if enough people flag something moderators step in.
My problem is not whether I “like” management’s tradeoffs they force me as a developer to make; my problem is that managements typically don’t take accountability for choosing to make them.
And then management (and their allies in the closely aligned “Software Craftsmanship” movement) blame the developers for the consequences of those tradeoffs and all the technical debt that typical entails.
“One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions.
I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything.
I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova.
I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...
“My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, https://news.ycombinator.com/item?id=20017854#20021832
“I regularly ask ‘Why are we running a marathon in a thousand sprints?’.
Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for ‘high velocity’. There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.”—epage, https://news.ycombinator.com/item?id=20017854#20021832
These designs are usually added to show the executives of the company that a branch of the org chart and its Important People can "add value".
Conversely, the fastest way to turn around a failing company is to search through company e-mail archives, find everyone who has ever used the phrase "add value", and purge them from the company.
> the fastest way to turn around a failing company is to search through company e-mail archives, find everyone who has ever used the phrase "add value", and purge them from the company
but you'd purge the entire c-suite if you did that!
I've come to understand that the most important part of any software project is the Critical Twenty, the first 20% of the project's timeline where developers' need to do things like gain a deep understanding from reading documentation and lay down the infrastructure and architecture and foundation necessary to support features above.
On a 10 month project, this translates to reading docs and putting down foundation stuff, and delivering no features, for the first two months.
Attempts to abrogate The Critical Twenty are what causes the majority of problems later on in most software projects.
https://github.com/rayfrankenstein/AITOW/blob/master/README....
Agile has fundamental structural problems which, combined with office politics which it can destructively amplify, make it an inevitable nightmare to work in.