Have You SCRUMed lately?

"What's that you say? You want to make a game! Wonderful! Go write or license an engine and show the world your talent.

Got the engine, huh? So where's the game? Ah, I forgot to mention you need to research the engine until you're proficient, then you can get started on your dream concept. Go, research, and create!!!

So, where's the game? What do you mean you can't make it by yourself? Ohhh yeah, you should probably form a team of artists, programmers, and maybe a designer to help you complete this amazing project.

Uh, oh! You've got the concept, the engine, and the team. How can you still be stuck? Why isn't the game made yet? What's going on?"

This blog is intended for developers working in a team environment. Solo-developers might find this useful, if they have a habit of treating their project as if it were being worked on by a group (source control, Gantt chart, turbo team meetings).

The satirical setup to this blog proposes an issue that should be addressed if you, as a project lead, want to keep your team organized. How are you going to manage the software development process? As friendly as completely mutual control distributed amongst team members may sound, this approach is idealistic and doomed to failure. Exerting control over a group of people and planning a project has two major risks I'll address: acting like a dictator and preparing a plan that does not allow for unpredictable events.

Organization Without Fascism:
Here's my situation. I am currently in the process of forming a team. I currently have two members, my best friend and my girlfriend. The first wave of team invitations will be sent to former classmates and friends. I know these people on a social level, and am aware that we all get along and would have fun creating a game. My primary goal is to complete this game, but I also want the journey to be fun for everyone and end the project with the same number of friends.

Preparing For the "Potholes" Before You Run Over Them:
Some prodigy developers can write a game start-to-finish without ever forming a development plan. Good for them. For the rest of us Indies and "first time teams," a little planning can save a lot of time down the road. While pre-planning and organization can be great, I am a firm believer in leaving room for change and unknown obstacles. If you want a great example, search the GG forums for people porting their games from TGE 1.4 to 1.5, or TGE to TGEA. Be ready to face the fact that requirements are going to change and unpredictable events will occur.



SCRUM It Up!:
There are quite a few methodologies practiced by teams serious about completing a project. The Waterfall and Spiral approaches are great, but my preferred management setup is Scrum. If you know rugby, you know what a scrum is. If not, Google it, because this is a game-dev article.

There is a good chance you might have experienced a few characteristics of Scrumming, and didn't even know it:

• Non-linear development process[li]Flexible scheduling and deliverables[li]Small teams[li]Frequent reviews[li]Collaboration between and within teams[li]And so on...

Developing under the Scrum methodology is a lot like playing for a "backyard sport team." You have a small group of people working individually toward the same goal, occasionally pairing up on tough "plays." Your coach is called a Scrum Master. His job strictly pertains to the implementation and management of the Scrum process, not the entire project. As the project lead, you can take on this role (like I will be doing), or hand this off to another capable team member. Aside from sharing the weight of management, the Scrum Master blocks outside interference from affecting your development team.

Now, I bet some of you are starting to think this process is sounding more and more restrictive and complex. "Here comes the 2 hour meetings, TPS reports, and flowcharts." At this point, the genius vision of the Scrum founders is realized. Instead of bogging down your developers with massive milestones separated by six month gaps full of meaningless and drawn out meetings, Scrum segments the projects into 4 week sessions called Sprints (another sport term). There will be meetings, but they will not last longer than 30 minutes. Only having thirty minutes to discuss the current project progress ensures only the important issues will be covered. Enter the Scrum Master, who asks each team member these 3 questions:

• What have you done since the last meeting?[li]Run into any problems?[li]What will you be working on until the next meeting?

Since we are looking at rapid application development, the conversation is only between the Scrum Master and the person being asked, and the Scrum Master has to make quick decisions to remove impediments and resolve team issues. You can't get more efficient than that. Efficiency aside, problems that crop up are addressed immediately and future plans are set up on the fly.

Believe it or not, this is over 75% of Scrumming. At the bottom of this blog is a link that goes into more detail, addressing backlogging (crucial!!!!!) and the five phases of a Scrum project from start to finish. The methodology can is highly adaptive as well. The last team I was on had five months to create a polished game demo. We had one month for creative design, one month for technical design, and three months to code. It wasn't until the fourth month that we realized we were Scrumming, except our Sprints sessions were every two weeks, instead of four. Under this methodology, we were able to write our own engine and create TWO distinctly different games before the final deadline (a Doom 3 clone and a Marvin Spectrum clone). Since my next project is expected to take up a year or two of my life, I'll probably implement the original Scrum methodology. I highly recommend any newly formed teams to look into this approach, because I found it works best for those who want organization without all the boring and stifling protocols. Happy developing everyone!

A Wikipedia Entry on Scrum