This is an individual's ranting as he generalizes his own agile experiences to everyone's, -even while he recognizes that the generalizations people make about waterfall are straw men-. What an amazing lack of self-awareness.
Worse still, even if I granted him his points as broadly as he seems to want to make them, and agreed that all agile/scrum experiences are like this (or at least, those in consulting), he fails to give any suggestion as to how to improve things. He dismisses both agile and waterfall. Okay then; how would you do things differently? 'It’s time for most of “Agile” and especially Scrum to die' - fine, to be replaced with -what-? I'm not interested in generalizations that you whine over; whether or not you're correct becomes immaterial if you -legitimately offer me something better-. But this offers me nothing.
I've gone around and around with others, and apparently articles like this must be interesting to most of HN's readership. It's got more than a dozen points.
The Guidelines say to flag it and move on, but maybe we can get a nice meta conversation going this time.
I think there are enough employers out there that are implementing the version of Agile/Scrum described in OP's post. I currently work at such company and can relate with pretty much everything on that post.
The sad part is I'm not really sure what is better that will be accepted by clients who now have become comfortable with Agile. From my personal experience, if you're on a team with smart motivated people, Agile won't really help you or increase your output. You will continue to deliver the quality work regardless of story points, scrums, and all the other metrics.
If you're not on such a team, clients using Agile can now point to some number and say "Hey, this number is 100 but you should be at 180. You are not performing". I do agree that it gives too many false positives and generally my attitude towards them (in cases where I have been the target) is to simply reply "If you don't think I'm performing: fire me."
They usually walk away at that point mumbling something and I go back to work.
You beat me to it. My favorite working environment ever was fanatically agile+scrum (from before I started working there), and it was the most wonderfully low-stress, highly productive place I've ever been.
Agile done wrong might be awful, but done right is a worker's paradise.
Another article about "How I didn't understand how to use fire and burn my house and myself to death". And I guess he doesn't know agile history to talk about it:
- "The “Agile” fad grew up in web consulting" - It grew up in huge enterprises in the beginning of 1990;
- "dealing with finicky clients who don’t know what they want" - just haha, I guess no one don't know what he or she wants in terms of development;
- "second is appealing to a decision-maker who’s recently been promoted to management" - looks like someone got not a best relationship with a managet in a past.
This starts with a false statement--"The “Agile” fad grew up in web consulting"--and just continues downhill.
I'm going to try and not make this criticism a No True Scotsman, but this post describes a vaguely Scrum-flavored approach that explicitly violates many of its stated intents.
If the purpose of this post was to decry cargo-cult agile where the trappings and software of Scrum or Kanban are adopted without paying heed to the intent, I'd be wholeheartedly agreeing. But it seems the author has conflated the two.
If information is flowing only one way, from product owners to engineers, whose only upstream delivery is their reporting, you're not looking at agile but at some weird sprint-chunked waterfall process.
I assumed I know what a scrum is, given that I'm in one every day, and I can't recognize what the author is talking about.
You're only able to give short-term updates? It takes 5-10 hours per week? What even is this?
That just sounds like a sinkhole of terrible management, where some micro-manager is scheduling a full-blown meeting every day and euphemistically calling it a "scrum".
I've worked at a company where Agile/Scrum was implemented in beautifully and we never thought to change the process.
However, I've worked more often at companies where Agile was either misunderstood, or inserted into an already flawed/toxic process of development as a magic bullet. I think there are enough places out there doing the latter that warrants discussion of this post and how we can improve things.
Totally fair, and agreed on the value of such a discussion; Same deal - seen/lived both. It requires fundamental cultural change (PM plays a big part). When the discussion starts with teams engaging in poorly defined scrum, I usually reference: https://www.scrum.org/ScrumBut.
