Learn Scrum: yes. If only to learn about it to add to your general skill set. (but a flavor of it "Scrum-ban" is probably what you are looking for...)
Scrum is a nice framework, but a core tenet is "Iterations (Sprints) shall be fixed duration" I've never seen this work in very small teams that are more interrupt driven than not. If you can truly sign up for and commit to work in a fixed time box (1 week?) then Scrum is a cool framework. If you can't... then Scrum is nice to learn about because it has some good concepts that translate well to other things... like....
Backlog - Scrum or not, keep a prioritized list of things you need to do. I like Excel (or Google Doc Spreadsheet...) You might like something else. I'd keep a very small tool if you are a very small team. (Spreadsheet >> Word processor because you can sort easily.)
Separation of planning and committing - Plan in an abstract notation (points) and be consistent (8pts is about 2x a 4pt story and 4x a 2 point story) When time to "do the work" re-look at the problem and sketch it out in hours. Don't change the points.
Commitment - be visible to others when you commit, and deliver on your commitments
Retrospective - after you have delivered, reflect on what could have been done better.
Scrum is easy enough to understand that it might be a good starting point. If you like it, I'd consider using the "Scrum-ban" variant - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban. Nothing else strikes me as "so well documented" with a reasonably active community to support it.
I'd love to also recommended Alistair Cockburn's Crystal methodologies (http://alistair.cockburn.us/Crystal+methodologies+main+foyer and http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology-Small/dp/0201699478/ref=ntt_at_ep_dpt_3), but it involves way more reading and digging.
Things like XP provide more details on specific practices, so I'd also say read the book: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s=books&ie=UTF8&qid=1304359834&sr=1-1
Final reading advice: So long as you agree to the Agile manifesto, and follow the principles: http://agilemanifesto.org/principles.html you should be in decent shape.
Adopt TDD (non-negotiable, IMHO)
Maintain a backlog (as per Scrum)
Always keep it sized and sorted on priority
Decompose things "too big to do between interruptions" int smaller chunks
Have someone else set/review priority (no two items get the same priority. ever.)
Make your build environment able to build/test/deploy (to lab env) in 5-10min
Show your customers (internal and external) the results of finishing a story
Story isn't done till your customer agrees.
Pull Stories from the top of the pile and work on them as you complete the current story
Don't keep more than 2 things open at any one time.
Finish one distraction before starting another.
Take pride in your work and once a month show the team/company all the products/features you have completed.
hope this helps