Agile is Poisonous
mdubakov.com
mdubakov.com
This is the most common Agile failure mode I've seen. You have to finish by the end of the iteration, so you're very heavily biased toward ugly hacks and Rube Goldberg machine coding. Elegance never fits in a sprint.
The last total Agile Kool-Aid drinker company I worked for also coincidentally had the most massive shit heap of code I have ever seen in production. It was a heterogenous mix of VB.NET, Ruby, Java, shell scripts, and Python running on Linux and Windows (and a bit of Mono on Linux), all glued together with duct tape and chewing gum. The Scrum Master was really proud of it, called it a Service Oriented Architecture. He could make pretty charts of it that made it look good, but if you lifted the hood it looked like garbage and required at least 10X the Amazon EC2 footprint it should have required. It was probably also a security nightmare, and was definitely hell to maintain.
That experience really destroyed my interest in Agile, since I could see very clearly how the problem was emergent from Agile's short sprint and exclusively deliverable-focused structure. The programmers were actually decent coders, and it wasn't really their fault. (Except maybe the heterogeneity...)
Wrong. The worst code I have ever seen. Written to pass tests, unmaintainable, fragile as hell due to the turtles-all-the-way-down architecture of relying on a thousand-and-one third party gems (and the checkins showing how frequently that very same code barfed and broke 'vital' things').
Agile is a pox upon software development, but hey, it sells books, provides employment for otherwise unemployable 'project managers' and finally putting to rest any semblance of engineering in software and systems today.
You need a strong leader to get the team to buy-in to these processes. Of course nothing will work if you don't do that - people are generally averse to change and will do anything to prove "new ways" will never work.
1-2 week sprints, Mini-waterfall, bringing back deadlines. I've actually been thru this kind of "fr-aglie" implementation by bone headed leaders who were aware of the buzzwords and hadn't carefully examined what the process(es) entailed.
People are going to rearrange processes, to produce the same things, for infinite generations to come. Probably best if you focus on what's getting produced, not who has the tomato, because the process is going to be something else in five or 25 years but you're still going to have to produce.
Users don't care what happened to the tomato.