Essentially, the only common theme is that there are morning meetings where everyone on the team wastes the majority of the morning describing what they've been working on (which 80% of the time is either "the same thing I worked on yesterday" or "bugs". The other 20% of the time there's actually some coordination discussion happening).
Wow... You've been in bad places
I've been able to keep teams of up to 21 people to tell everything under 5 minutes. There IS a way to go about it efficiently... That being said, scrum works better between 6 and 9 if possible.
The more efficient teams I've worked with separated the morning meetings by department: A programmer-only meeting, an artist-only meeting, and a designer-only meeting. The different departments very rarely need to tell each other what everyone on the team is doing every day, so reducing the number of people per meeting means that the round-the-room goes faster and those people can get back to work sooner. Even better if the different meetings are in parallel, but unfortunately the producers typically need to be at each one, so the meetings are staggered throughout the morning.
I tend to disagree. A well organized project that has a sufficiently large structure would rather split between features. That would imply that each smaller scrum entity is composed of cross-functional resources, possibly a programmer, an artist, and any other relevant person (possibly a development QA, a UI designer, a game/level designer, etc.)
Then, you're likely to want to do a scrum-of-scrum to avoid overlap and maintain communication channels open without impacting production.
As a non-management person, the only thing you'll do in the morning meeting is say what you're doing (during Beta phase this will literally be just "Bugs." until the managers get bored with that and reduce the meeting frequency to once a week). If anything's blocking your progress, mention that. Then it continues to the next person.
The context generally goes as follows:
I've finished this yesterday. I'll do this today. This blocks me, can you lend a hand Tod?
Once everyone has spoken, every person that can unblock somebody else will look at the list of people they are blocking and will reassess their duty for the day to make sure they unblock everyone they possibly can.
It is unecessary to mention each and every bug, just like SCRUM isn't a statement of what you're doing, just a context of what needs to be said. Too many newcomers think of it as a statement to the manager.
As a management person, you'll be taking notes about what each person says during every meeting, thinking about scheduling and load balancing tasks to workers. You'll be announcing any important news and reminding people of particular deadlines, and potentially setting up 'normal' meetings to actually discuss specific features/goals with the appropriate people.
There aren't really any management roles in a scrum. The scrum master is not a manager, and is actually part of the team. The scrum master is meant to keep mental notes of the headlines to report to the Product Owner if needs be, but most importantly, he needs to take notes of blockers. His duty is to help the team get unblocked (his job is to run point on any task that might help remove blockers for everyone else). That can mean, buying doughnuts.
The team is responsible for load-balancing itself, the scrum master isn't in charge of doing that.
One of the things I personally do with my team members when they grow into older habits and ask 'I was going to start working on that, but this guy needs me to do this, yet, this other guy needs me to do what I'm doing, what should I do first?'. I just say 'talk with them, and see what you think is best in the interest of the team'. That's SCRUM's spirit.
There's no need to practice something like "scrum". It's mostly a joke to keep project managers busy with something, so the rest can get actual work done.
While I disagree, I tend to prefer Scrum-ban for this reason. The sprint planning consumes a lot of time. It takes time before a team sees value in it, and a lot of people will go into it half-heatedly. While SCRUM is valuable, it takes too much effort to implement successfully for the net gain. Scrum-ban is more intuitive in that it essentially feels like a developer's notebook and thus requires no actual transition. It is just a way to expose that actual notebook to everyone, reducing the amount of questions management needs to ask you while you're developing.
I see that a lot of individuals here have a warped understanding of scrum, and this could be in part because a lot of businesses implementing scrum has no knowledge of what it really is about. It can be a big buzzword, and the difference between the appropriate implementation, and playing with the words, can put you in a world of hurt.There is however a said way to do scrum that works.
That being said, to the OP's objective:
There is no real reason to practice scrum as a single individual. Scrum works best as a set of guidelines to regularize how you interact with a team and a product backlog. Assuming you're a one man team, this means you are both developer and product owner. There shouldn't be a real reason to help you facilitate communicating with yourself. The only concern you should have is creating the backlog itself, and managing it over extended periods of time.
If your intent is to train yourself so as to make yourself more desirable to companies, try to take some contracts on the side instead. You'll gain much more viable experience in dealing with a product owner by doing so. Dealing 1-on-1 with a client will actually net you a lot more experience in that regard than most developers. As a manager, working with people that used to freelance has a definite plus: they understand the reason for the things that I do, and thus, they have learned how to give me maximum exposure of information with as little time as possible. Likewise, I don't need to bother them with questions.
In a scrum environment, this experience translates as being able to select the information that is relevant to share. No one cares what you did if it went fine and nobody was involved. It's cool for the project, and you can tell your sweetheart tonight, but as far as the scrum daily stand-up is concerned, just skip ahead to the meaty part that requires you to say 'I need John today to fix this mess'.