I really want to practice this framework called Scrum seeing as it seems to be commonly used or practiced in the game and software industry and it actually might broaden my horizons in my solo efforts as a game programmer hobbyist. But it seems I am a bit out of luck in the "team aspect" of Scrum seeing as I am a lone wolf in the programming side of things.

Below is the statement I found about the Scrum framework:

Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole.

I need suggestions on how does an individual practice Scrum even without a team?

I figure if I know the process before joining a team in the future who knows Scrum will be an easy transition right?

I never worked in a team before. I worked alone making games as a hobbyist. I've been programming games for a year and a month.

Scrum is a buzzword - companies and teams will use the term even when their process is completely different than other companies/teams. There is no point practicing something as nebulous as that (especially without an actual team). You first need to find out what implementation a team is actually using.

I've experienced several different teams who all had different ideas of how scrum should function. 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).

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.

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.

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's nothing special you need to practice (unless you have a phobia about speaking in a room full of people), and without an actual team, there's no real way to practice.

Practicing the "team" parts of scrum by yourself is almost impossible, as you are not able to reproduce the interpersonal relations of a team when you are alone. However the project-management parts are easily doable by keeping a high-level backlog, dividing it into stories and then into simple tasks, the way Tom wrote.

One of the key aspects of scrum is to have a "potentially shippable" product after each sprint, which is a very nice goal to train to. Have something working that you would be confident to display after a certain time greatly helps to get things done.

Also instead of practicing, get some reading done. I highly recommend "Scrum and XP from the trenches" (downloadable here: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches ) for a practice-oriented read, if you already know the basics about scrum

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.

We used to have a development method that worked pretty well. Then orders came from the owners to adopt scrum. In practice, things just turned into the wild west instead, with everyone just doing whatever they please.

Amazingly, this has enabled us to get more work done with higher quality than before.

Amazingly, this has enabled us to get more work done with higher quality than before.

That's great!

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'.

Good luck!