| The article (the one inside) simply says that one size doesn't fit all. Agile (or, as I like to call it, short and iterative waterfall with priority management and pipeline solution), fits some scenarios well, but not others. It fits startups because it's quick to release. It fits non-scientific products (or non-algorithm heavy products) as features can usually be contained in a single sprint or easily broken into deliverables. It fits huge products on maintenance mode when most of the development are customer features and issues. However, it doesn't fit algorithm-heavy products (algorithms are usually "one-go" and require a sustained effort), it doesn't fit big products during intense development (architecture can't be ignored or it'll crumble under the product weight), it doesn't _always_ fit corporate environment (because of "impedance mismatch"). [very personal opinion, flame-shield on] It fits average developers since it maximize oversight, reduce the time an error has to propagate and forces the work to be split into manageable, chewable parts. It doesn't fit great developers ("distinguished", "level 4", "star"...) because, just like any other artificial framework, it hinders creativity and the free flow of code. On the other hand, a great developer is also measured by his/her ability to ship - which negates the need for such artificial systems. [/very personal opinion, flame-shield on] |