I think this list is a bit too focused on big, dedicated software companies. If you're spending a month or two making a throwaway bit on analysis, for example,

I think this list is a bit too focused on big, dedicated software companies. If you're spending a month or two making a throwaway bit on analysis, for example, maybe it doesn't need hallway usability testing and plugging into a CI system (although I'd argue for a makefile, which maybe does the same job). Similarly, if you're not collaborating on a thing, maybe you don't need a schedule. You can do the job with an ordered list of tasks and a future date when you'll revisit that list to see if you need to ditch some things to stay within the budget. And if your company only has a couple of developers to support the business, then you're probably not going to hire dedicated testers or UX specialists (how much longer before that gets replaced with some other buzzword anyway?). And actually, all these things can be changed. If you go to a company that doesn't do something that you think is important, then make your case. If you're in a position where your case won't be listened to, that's a much worse indicator. I wouldn't work without version control though. If I have to be responsible for some text then it's going in Git, be it code, configuration or notes. On a different tack, I think the idea that a spec isn't useful any more because of agile is definitely a wrong one. Your spec doesn't have to be absolutely rigorous, set in stone, or meet some standard. Writing down in detail what you intend to do and how it will meet your aims is really useful for non-trivial tasks.