>>Uuumph, to broad a question. It depends a lot on the quality of programmers in your team, how much you can deend on them to work on a project without going astry or how much herding is necessary if they tend to loose focus on main objectives. If you herd lots of cheap programmers, Agile will help you. If you want to accomplish the task with few, but highly competent programmers, don't waste programmers time with Agile group stupidity.
>
>Follow-up....first, you're my new hero. :)
>
>Second....at risk of sounding harsh, that "stupidity" that you (accurately) described can be found in I.T. managers who a) are often the ones forcing developers astray, and/or b) blindly adherence to metrics
>
>I know too many managers who believe that Sprint metrics are more important than user satisfaction and quality. Their position often amounts to the mindset of, "The operation was a success but the patient died"
>
>Third....you're my new hero. I'm going to start using the acronym AGS (Agile Group Stupidity) and I'll definitely give you credit. :)
>
>If anyone detects any level of anger, it's with the managers in the world who do not understand the difference between what you described....experienced and focused developers who know what they're doing, and developers (even well meaning ones) who need some discipline.
>
>At best, I think Agile and Sprint (and even so-called hybrid Sprint) are short-term corrective measures, with some merit, and best for OLTP type applications. And that's it.
>
>I often tell people I'm agile with a little 'a', not a big 'A'. I've been using short tasks and iterative practices (like many veterans) when some of these industry Agile 'coaches' were graduating high school.
>
>If developers "like" Agile and the metrics, that's all fine and good. At some point they will work the parts of agile that make sense into their work process and eventually won't need it. In that sense, agile is like a 12-step program to get people back on track.

I've been doing this for a while.
Agile had lots of predecessors.

PERT - Program Evaluation Review Technique
CPM - Critical Path Method
Decision Tables
Structured Programming
Object Oriented Programming.

All, at one time of another, were considered the sine qua non of this business.


A wise man once told me that there are things you do to look as if you know what you're doing and things that you do because they get the job done most efficiently, and they're really the same.


>
>OK, enough ranting for Saturday night.