In the same way that a UX designer is responsible for creating an excellent user experience, a Scrum Master is responsible for creating an excellent project experience for those people who use the team to turn their ideas into reality.
By looking at the "team" from the external perspective, we can easily narrow down those bits of Scrum that are relevant even when the team is made up of one person.
A Scrum team provides:
- transparent insight into the team's progress
- an idea of what stakeholders can expect to see every Sprint
- an opportunity for stakeholders to provide feedback
- the chance for stakeholders to change their mind and / or direction every Sprint
- working software.
If a team member is working as his own Scrum Master, he can still provide these things by keeping a visible Scrum board, meeting with the stakeholders to prioritise work, working towards the Sprint showcase, responding to feedback, and releasing valuable software. How he chooses to do that within the limits of the Sprint will be his own business, just as it would be the team's.
If a single programmer is also working as his own Product Owner - for instance, he owns a one-man company - then he won't be constrained by the need to communicate with external stakeholders. He can create his own priorities, release code as-and-when, and get feedback directly from his users. In this case, I'd look at Kanban, simply because of the focus the WIP limits provide and the more flexible cadence.