What you wrote and what I wrote I don't think conflict at all, so I don't know why you'd say it is working against me. Also I have found references to what I wrote in writing so I'm not completely crazy.
Now, an anecdote that I might screw up because my memory is fuzzy about it, is that the founder of Instacart was given a copy of Webvan's business plan on a floppy as a sort of "Good luck!" token.
I think the first thing to note is that: there is no 'right way' to start a start-up, though there are probably some wrong ways and things to avoid. To that end, you probably only need to do a minimal amount of reading, and then it is very much all about doing. Only once you start the process will you begin to see specific gaps in your knowledge or a bump in the road you need to get over. This where specific reading and resources will be 10x more valuable than general roadmaps.
However, these are good resources:
http://www.bothsidesofthetable.com/on-entrepeneurship/ - Mark Suster's blog is excellent, and his indexed start-up advice is an amazing resource to being with.
http://www.amazon.com/The-Startup-Owners-Manual-Step-By-Step... - this book is very much in vogue at the moment. I have it, and it makes a lot of sense, and takes you one step at a time down the most important path of all - product development
http://www.quora.com - this should be one of your best friends, as it has a huge amount of start-up related advice
Hope this helps.
With agile, sometimes the word is used to justify a rigid excess of ceremony, or as a firewall for lazy developers to hide behind to avoid being responsive to non-engineering members of the organization, or as an unrealistic attempt to turn software development into an assembly line of a bunch of jack-of-all-trades "cross-functional" team members ("specialists? we don't need no stinkin' specialists!"). But the core observation of agile is that writing huge planning documents and spending weeks perfecting PRDs and GANTT charts at the outset of an engineering project and then using these to derive project timelines and costs is inefficient, and that "delivery to QA" 3 months over an arbitrary schedule and 70% over an arbitrary budget is a classic failure mode for this approach to planning. Instead, a focus on building self-organizing, trusted teams who are delivering working software frequently and iteratively, and gathering customer feedback and adjusting "the plan" after each delivered increment of software can result in both happier developers AND happier customers.
Similarly, "lean startup" CAN be synonymous with "changing my mind about what business I'm in and 'pivoting' every 3 weeks", but really the core observation could be summarized as "build things people want", with all these new-fangled buzzword-y tools like customer development interviews, business model canvases and even "pivoting" as a means to this end. While the Ries book is useful, Steve Blank's The Startup Owner's Manual (http://www.amazon.com/The-Startup-Owners-Manual-Step-By-Step...) is phenomenal and the ideas there certainly "transfer very well outside the world of tech start-ups."
Take what works, leave what doesn't, ignore the hype and think critically.
Get dozens of book recommendations delivered straight to your inbox every Thursday.