<i>sigh</i>. It's nearly impossible to have a meaningful conversation about anything to do with "agile" these days. And that's because there's approximately zero agreement about what "agile" even is, and all of the various terms are overloaded with 100 different meanings, and every "agile" implementation is different from all of the others.<p>I'll just note that, in my experience, a few things are true:<p>1. The Agile Manifesto, in and of itself, is great.<p>2. There is no such thing as "agile development", as a methodology in its own right.<p>3. There are many "agile" methodologies, including Scrum, SAFe, Disciplined Agile Delivery, Agile Unified Process, Crystal, XP, etc. And then on top of that, every company in the world has implemented their own poorly specified, half-assed, bug-riddled, barely comprehensible implementation of "agile".<p>4. Approximately everybody misunderstood / misunderstands (perhaps intentionally at times) the Agile Manifesto and bends it to suit their own biases. A classic example is illustrated in this article:<p><i>One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is "Working Software over Comprehensive Documentation."</i><p>NOWHERE in the Agile Manifesto will you find any instructions saying "Don't do requirements engineering" OR "Don't identify requirements up front". I promise. If you don't believe me, go read it right now and see if you can find those instructions.<p>What you will find instead, is the quoted admonition to NOT put documentation (possibly including requirements) OVER actually delivering software. But the Manifesto itself clearly says "there is value in the items on the right". Where "The items on the right" include:<p>- processes and tools<p>- comprehensive documentation<p>- contract negotiation<p>- following a plan<p>Unfortunately we, as an industry, collectively managed to myopically focus on items on the left and the "we value the items on the left more" phrasing and threw the baby out with the bathwater. "We are doing Agile" became the excuse to abdicate with regards to the necessity of doing requirements engineering, architecture/design work, documentation, etc.<p>Basically, we swung too far in one direction, and need to move back towards the center. No, I'm not calling for a return to waterfall or anything. I'm saying that we can embrace the principles of the Agile Manifesto and STILL DO requirements engineering, architecture, and all of those other things.<p>A good starting place would be to stop talking about "agile" like it's a discrete methodology (as opposed to a family of loosely related methodologies) and - as organizations - pick an actual methodology to implement and then <i>actually</i> embrace the "empiricism" attribute that Scrum emphasizes (whether or not you're using Scrum per-se)... measure things empirically and actually make adjustments based on THE REAL WORLD not somebody's whack ass theory. Reality trumps everything and I desperately wish we could get everybody to acknowledge this.