Eating up post-it notes ("issues") and crapping out code - i.e., doing agile - is just not gonna cut it. When the end goal is a robust, resilient system that c

Eating up post-it notes ("issues") and crapping out code - i.e., doing agile - is just not gonna cut it. When the end goal is a robust, resilient system that customers depend upon to suit their needs and your organization depends on for its business, by doing Agile you're going to end up with something that neither your customers nor business can fully rely upon (once your system or service is past a certain level of complexity). Two major reasons: 1. A set of agile "Issues" (whether stories or bug reports) do not constitute a necessary or sufficient set of tasks necessary to produce, release, and operate a resilient or complex system. 2. You know the phrase that "Not everything that can be counted counts, and not everything that counts can be counted"? Agile gives you utterly meaningless metrics (e.g., story points) that can be counted, but don't count. What does count depends on the nature of your business or product: Small start up? Probably revenue or users. Large-scale infrastructure system? Maybe average latency or uptime. Unless you can directly correlate "story points" to your bottom line, just skip that clutter in the first place. Call me old fashioned, but I found that when you bring engineering back into software development, specifically systems engineering (not "engineering" in the sense of "I'm a ruby-on-rails engineer"), products and teams are able to support a high level of confidence and reliability in their work products. This means (yup) requirements engineering and analysis, QA, Independent Validation and Verification, etc etc. It does not mean you have to have full departments for each of these, but at least having someone to "own" each of these areas (esp for small teams). Again, in the end, no amount of stuffing post-it notes down your developers throats will replace old fashioned engineering process and engineering management.