I don't know how I can constructively with you. I'm aware that there are things other than Agile and Waterfall. I'm also reasonably sure that you don't think good project managers magically make teams more productive. But you've done nothing other than trash Agile, dismiss Waterfall, and offer no alternatives of your own. How do you like to develop software?
I get what you're saying about "tell me what you want to do first, and we'll work together from there". I mentioned a few times in my post that it's always important to not blindly implement Scrum, but to see what works well from you. But having Scrum defined is still useful for a lot of people, since:
- It gives you a starting point to work from. Every project is different, but there's certainly common elements to projects as well. It's a bit like design patterns in software - applied blindly and religiously, they're impractical and can lead to pitfalls, but that doesn't they can't serve a purpose.
- It takes a lot of time to learn what works and what doesn't in regards to project management. Telling new managers and developers to figure out what works for them with no guideposts is just going to lead to a whole lot of inefficiency as everyone stumbles towards a (mostly) shared goal.
In regards to projects taking longer under a waterfall approach vs. an agile approach, there's a lot of different reasons for this sort of thing happening.
- Working on small sprints (or whatever you want to call them) instead of month-long projects saves you a tremendous amount of integration time. Show me a project under active development that's existed outside the production branch of a codebase for more than a month that isn't going to be a nightmare to integrate.
- Forcing yourself to make decisions up front, especially when you have a strong product management component to your team, can result in drastically more time working on requirements instead of starting with some unknowns and letting them work themselves out.
- I can probably point to several bits of these projects that we would have avoided doing or would have done differently with Agile, but the requirements said otherwise. It's amazing how much power requirements documents have, and how much inertia they can add to a project.
- Stuff generally gets done close to the due date on a project. This is as close to a universal truth as I've ever seen in project management. By keeping everything in tight iterations, you can control the flow somewhat by putting pressure to complete releasable software every week, rather than one massive due date that everyone scrambles for at the end of a project.
- Being able to "re-evaluate project plans" is a hallmark of Agile, not Waterfall. I agree, being able to re-evaluate and iteratively arrive at a solution outside of rigourously documenting things up front would make things a lot more efficient. That, far more than planning meetings and retrospectives, is what Agile is all about, so I'm not sure why you're so intent on trashing it.
I'm not sure why my example is ludicrous. If the process used doesn't have any effect on how long it takes to develop a project, what's the point of any process in the first place? Of course using different methodologies will have different results - even if you aren't an Agile fan, that's completely obvious.
You're not trying to be constructive. You're blindly trying to force your points through without shouldering your responsibility to provide proof for your claims.
The only credible evidence I can find about Agile's supposed benefits is the Voke report, which warns against using agile. With only 28% of participant reporting success with an Agile approach. That's bad. Plain old fashioned bad.
It's like I'm debating a creationist. Your logic is circular. You want me to believe the Agile works, and you're more than happy to tell me how wrong I am, but you shoulder none of the responsibility to prove your claims. At best, you're suffering from confirmation bias, but I think that's being too generous.
And stop talking about waterfall. It's a false dichotomy. You're the only one making that comparison.
Your argument, as far as I can tell is two fold.
Some process is better than no process: Well I think every sane person would agree with you there.
Agile is process, everything else is no process: Wait... what? How do you keep on arriving at that conclusion over and over again? And don't even think about saying "waterfall" because I swear to god, I'll punch my computer so hard it'll knock Google off the internet.
Find me evidence as compelling and credible as the Voke report, supporting agile, and we'll talk sensibly. But I'll go out on a limb and say you can't, and you won't. Because if I were to draw on my anecdotes and present them as evidence, Agile is universally bad and dooms everything it touches to failure or 'third-rateness'. That's all the experience I have to draw on.
And I suppose that's my biggest bug bear about Agile. Teams always finish things wether some fool is ramming agile down their throats or not. There's no other alternative. But Agile takes great ideas, shatters them into a million pieces and churns third rate approximations of that good idea out the other end. Without Agile, I've seen projects that were horribly mis-managed but the output was still great and once all the screaming was over, I was proud of my work. There's something about Agile that makes for crap products, and I feel so ashamed of the output that I wont even put my name to it.
> Agile is process, everything else is no process: Wait... what? How do you keep on arriving at that conclusion over and over again? And don't even think about saying "waterfall" because I swear to god, I'll punch my computer so hard it'll knock Google off the internet.
As far as I've been able to ascertain, in practice, "Agile" means "not waterfall". Fullstop. As in, any process that isn't waterfall, is called "an Agile process."
You can be "agile" by just goofing around with no big plan; if the work gets done, you can look back at the points where you made little plans, and say "well, see, we were doing Agile." Any [successful] process other than waterfall, when post-hoc analysis is applied to it, will look like the classic definiton of an "agile" process, no matter whether you were trying to execute capital-A-Agile at the time!
And I'm not saying that in the "the Agile people are right" sense. I'm saying it in the vacuous sense: that the term "Agile" is meaningless other than in that it means "not waterfall." Waterfall is doing design once, at the start of the process. If you ever do design again at any point, ever break your design up into pieces and postpone some of them, or design this feature at a separate point than that feature--then you're not doing waterfall. And so, the Agile people will say, you're "doing Agile." That's it. That's all they mean. You've designed more than once.
And your response should be "...so what?"
(But it should also be, in a more diplomatic sense, "well, then we're all doing Agile already anyway, aren't we? You've long won this Quixotic crusade against the Waterfall windmill; we all agree that 'Agile' (to this vacuous definition) is the right thing to do. Now let's all go out for a pint.")
I get what you're saying about "tell me what you want to do first, and we'll work together from there". I mentioned a few times in my post that it's always important to not blindly implement Scrum, but to see what works well from you. But having Scrum defined is still useful for a lot of people, since:
- It gives you a starting point to work from. Every project is different, but there's certainly common elements to projects as well. It's a bit like design patterns in software - applied blindly and religiously, they're impractical and can lead to pitfalls, but that doesn't they can't serve a purpose.
- It takes a lot of time to learn what works and what doesn't in regards to project management. Telling new managers and developers to figure out what works for them with no guideposts is just going to lead to a whole lot of inefficiency as everyone stumbles towards a (mostly) shared goal.
In regards to projects taking longer under a waterfall approach vs. an agile approach, there's a lot of different reasons for this sort of thing happening.
- Working on small sprints (or whatever you want to call them) instead of month-long projects saves you a tremendous amount of integration time. Show me a project under active development that's existed outside the production branch of a codebase for more than a month that isn't going to be a nightmare to integrate.
- Forcing yourself to make decisions up front, especially when you have a strong product management component to your team, can result in drastically more time working on requirements instead of starting with some unknowns and letting them work themselves out.
- I can probably point to several bits of these projects that we would have avoided doing or would have done differently with Agile, but the requirements said otherwise. It's amazing how much power requirements documents have, and how much inertia they can add to a project.
- Stuff generally gets done close to the due date on a project. This is as close to a universal truth as I've ever seen in project management. By keeping everything in tight iterations, you can control the flow somewhat by putting pressure to complete releasable software every week, rather than one massive due date that everyone scrambles for at the end of a project.
- Being able to "re-evaluate project plans" is a hallmark of Agile, not Waterfall. I agree, being able to re-evaluate and iteratively arrive at a solution outside of rigourously documenting things up front would make things a lot more efficient. That, far more than planning meetings and retrospectives, is what Agile is all about, so I'm not sure why you're so intent on trashing it.
I'm not sure why my example is ludicrous. If the process used doesn't have any effect on how long it takes to develop a project, what's the point of any process in the first place? Of course using different methodologies will have different results - even if you aren't an Agile fan, that's completely obvious.