"We tried 1 week and 2 weeks iterations. Neither worked out. With short iterations there was a constant pressure to get shit done and technical debt accumulated like a huge garbage heap. It is impossible to squeeze a good solution into a short timeframe."
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...)
This is common in a lot of Rails shops - they are so proud of the extensive Cucumber tests, of the endless gems required just to run the tests, of the layer-upon-layer of crap, and look all the tests passed, it must be good right?
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.
Good developers can only write good code if they can think and plan. Neither of these is ever a sprint objective. The objective of a sprint -- in practice -- is always to bang out the absolutely minimal quality hack required to complete the sprint's objectives.
Nothing distracts good developers to write good code. There is NO excuses. Bad management? Bad mood? Fuck it. Find another job if management can't live with good solutions. Again. No excuses.
I think even parody is too much attention in this case.
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.
In all honesty, the shortcomings written about here are not a defect in the process(es), but appear to me to be simply weak project management. Especially since your ScrumMaster just up and quit. That is unheard of in a strong project-oriented culture.
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.
Nicely done, at first I was in disbelief, but then realized that it's satire. It's unfortunate that I know of companies that have implemented so-called "agile" and basically didn't even get what the heck it was supposed to be.
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.
I thought this was hilarious, especially that on 'blame day' you couldn't defend yourself in Nerf battles. It left me wondering "Ok, what are these folks trying to do?" and then "Oh, he's one of the founders of http://www.targetprocess.com/ , I get it."
20 comments
[ 2.6 ms ] story [ 51.8 ms ] threadThis 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.
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.
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.