Maybe Personal eXtreme Programming might be something you might want to take a look at?
It's a method that is a combination between extreme programming practices and the practices of the Personal Software Process(PSP) devised by Watts S. Humphrey of Carnegie Mellon University.
PSP is quite rigid in its approach and not agile. PXP is a more agile adaptation of personal software development. PXP isn't really something you'd call mainstream, but I've used it in the past, and it has worked for me. I've adapted a PXP approach based on some papers I've read on the topic:
PXP involves the following PSP practices:
Basically your time sheet. This is useful to determine your rate of progress.
• Size Measurement:
You have to have some kind of metric to measure the amount of work you've done. Usually this boils down to Lines of Code (LoC)
• Defect Type Standard:
A list with which you catagorize the types of bugs you encounter.
• Process Improvement Proposal:
You have to have some kind of plan to improve your own process. Basically you'll need to plan some activities for self evaluation and review. You'll have to make a plan before implementing it. (And review the plan once in a while to tweak it)
• Defect Recording:
You have to keep track of the bugs you found so you can analyse your behaviour afterwards.
• Code Reviews:
This is a bit tricky, but somehow you have to review your code. I din't find this particularly interesting until I managed to mentally detach myself from my own work. Still you usually don't spot your own faults as easily as others do.
There area also some XP related activities:
• Continuous Integration:
PXP includes the practices of source control versioning, automated builds, automated test executions, and automated defect submitting. I find this practice very usefull. (I prefer the gated check-in approach, but that requires some scripting to set up, you might find that to be too much trouble)
• Simple Design:
KISS! You probably know what I'm talking about. (if not, google it)
• Small releases:
Make the milestones in your sprints small enough to keep things in perspective and not run the risk of spending a huge amount of time on features you've committed to, but can't deliver on in time.
Standard agile practice, really.
• Test Driven Development:
This too shouldn't be too unfamiliar.
• Spike Solutions:
if you have a problem that you're new to, or that is hard to solve, take a step back and try to solve it in a stand alone setting before you try to integrate it in your big project.
TL;DR: it boils down to the tracking rigor present in the PSP/TSP (CMMi) style combined with common practices of XP minus the team efforts that are required for XP style processes.