Why “Agile” and Especially Scrum Are Terrible
michaelochurch.wordpress.com
michaelochurch.wordpress.com
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.
But maybe it'll lead to a productive discussion on what it takes to run an effective agile shop, and that'd be worthwhile.
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.
Agile done wrong might be awful, but done right is a worker's paradise.
Didn't even read after 1 paragraph.
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.
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".
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.