> If you try to cherry pick the obvious shiny stuff while skipping the slow/expensive less-obvious things, you are doomed to fail. This is true with everything

> If you try to cherry pick the obvious shiny stuff while skipping the slow/expensive less-obvious things, you are doomed to fail. This is true with everything in life that you seek to do well: cooking, dancing, etc. > Really awesome Practice A (skipping up-front requirements development, shorter QA cycles) is made possible by really tedious Practice B (pair programming, TDD). A big nit: you don't exactly "skip up-front requirements development". First, the appetizer: One of the things you actively seek to avoid in an XP team is blocking: having people sitting around, doing nothing, because they are waiting for other teams/roles to hand them something. Another thing you want to avoid is building things that are not needed, wanted, or required by either you or your customers. Finally, customers are going to change their minds, and you can come to them with one of two answers, either, "we can't do that, it's not in the plan"; or, "sure, we can change direction". Now, the meaty goodness: You absolutely do market research, and probably have designers doing various types of prototype testing with Real Live Users (Or At Least Their Proxies) before you kick off any serious engineering work. This will yield a pile of low-fidelity prototypes, assumptions to validate, and a tentative roadmap upon which your whole team (Product, Design, and Engineering) can begin execution. You absolutely should have plans that stretch into the future, but the farther out those plans go, the lower their fidelity should be, because you are almost certain to change those plans as you build, experiment, and learn.