The banks that don't have them in stock will almost always be willing to include a brick of $2 bills in their next currency order to the Fed if you agree to take all 1000 of them. It takes me about a year to go through a brick just using them for small cash purchases.
The major problem with Agile is that it is the new software development buzzword, and thus is perceived as a golden bullet for software development. Agile has a specific application: development of experimental software, where the project sponsors know they need something in a particular area but do not know exactly what. Agile (and iterative development in general) lets the target change over time as knowledge is gained. Unfortunately, iterative development is expensive, probably twice as expensive as waterfall for the same result: "refactoring" is another word for "rework," and there is a great deal of this in iterative development. Agile in practice is typically waterfall without a project plan: the project sponsor knows what is desired, and when, and is trying to get it for cheap. Iterative development fixes the time taken ("timeboxing") and the cost (level of effort); what is unknown is how long it will take (or alternately how much you can put into a sprint). Starving Agile has the same result as starving typical development: you only get the 1/3 of the software that is apparent, not the 2/3 that makes that 1/3 truly functional, reliable, and maintainable.
The change from imperative/procedural languages to object oriented languages can probably be done through reading and experimenting, but an instructor-led course would be easier by far. If you can take one or two semesters at a local college of some object oriented language — Java and C# are the two most approachable, and conveniently have free IDEs and toolchains — that would put you back in the game enough to learn through reading and through playing around. Once you have your mind wrapped around OO concepts, a GUI framework (Swing, WinForms, GTK+, etc.) is easy enough to pick up. Similarly, learning how to exploit relational DBs is deserving of a course: I've never seen anyone self-teach more than about half of a relational DB's capabilities. I'd put off C++ to start: the language is fearlessly exploring what happens when OO concepts are applied orthogonally across a language, but Java and C# fit nicely into the 90% solution space that people actually use.