I start all kinds of projects with minimal requirements. You obviously have to have something to start but I'll go into a meeting with a notepad and suss out what's need enough to get started.<p>In my opinion, true agile is rapidly getting code in the hands of users as quickly as possible. Then iterating on that. You don't need a lot of requirements to get started. But need to be not afraid of change! Things will change (maybe everything will change) and that's ok -- plan for change. This author starts with the implicit premise that change is bad and all conclusions are the result of that.<p>I've been involved in a few "Agile" projects implemented in hard-to-change platforms. And ultimately it's just disguised waterfall -- if you can't change the product then you're doing big planning up front.
Needs an example and some diagrams, otherwise, it's just words.<p>"Don't start without requirements"<p>Depends on if you even know what the requirements are, some projects are just an idea.
I hate the term "requirements" with passion. It is almost always used by people without any vision or passion.<p>Why is it so unimaginable to create something without being able to articulate it beforehand? Or why wouldn't it be possible to start with something and letting it evolve by discovering new insights while building it?<p>How many successful things are really built by first writing down requirements?<p>Sometimes it is just an personal itch or curiosity. Other times it is actually total epiphany that brings success...