Team management tools and techniques

Unity Engine
1

There are several tools and strategies that can be employed while working together with a team. The most important thing to have on your side is a team development strategy. Our strategy of choice is what’s called Agile Dev strategy. We’ve modified it to suit our needs and you can do the same but I’ll give you a quick overview of how this works.

First off you have to have regular meetings, I know this isn’t something that’s usually fun but it helps keep your team accountable for what they’re doing. There are a series of meetings that must be held in the beginning of any project. After the initial idea is formed and hashed out in whatever manor you choose, most times for us it’s just a few brainstorming sessions that happen naturally, the rest of the process is as follows:

1.) Requirements meeting

  • Take the basic idea and together right a document that describes in vague details the users progression through the game and basic game mechanics.
  • Hash out any details about how different systems interact in a nontechnical fashion.
  • Be sure to split up how these ideas interact with each other to make a FUN game.

2.) Task Planning Meeting: This is where technical specifications come into play

  • The group writes a separate document that spells out in exact details the different minor tasks that must be completed to accomplish each requirement spelled out in the Requirements document.
  • These tasks must be in bite sized chunks like (draft character sprites for running, design back-end code for start menu, implement graphics for start menu, or record hit damage sounds)

3.) Scoring meeting: This part is a little difficult to understand at first

  • Using a point system from ‘1’ being a very quick and easy task to ‘10’ being the most difficult and time consuming task, the group gives points to each task in the Task Planning Document. All members of the team give what they think the points should be for each task regardless if they will be the one completing it or not.
  • Not everything has to be scored in the first meeting since the points will slowly be adjusted as they gain relevance. The points are arbitrary until work begins and everyone understands the difficulty of certain tasks.

4.) Sprint Planning: A sprint is a predetermined period of time a week, two weeks, a month. This will be used as the method for measuring how long the game will take to create. The team must decide when to hold each sprint planning meeting and hold to that day of the week every time.

  • Report individual task completion and record points
  • Sprint retrospective and sizing: A look back on how things went during that sprint and whether or not points should be changed on future tasks to better represent the work needed to complete them.
  • Announce to the team the current level/percentage of completion: Using the total points and the points completed you can give a percentage of the planned project that is complete. Also, after a period of time and an average points completed per sprint you can get a clear picture of how long it will take to finish the project.
  • Each member of the team pulls points/tasks to complete for the next sprint.

Once the game is complete a Full game retrospective should be held in this final game meeting the process used to complete the previous game should be reviewed. At which point, the process can be refined for future game. The process is never going to be perfect but it can be improved upon during every iteration.

Tools to help this process:

Dropbox : www.dropbox.com

This is a cloud data storage system where the team can share any files necessary for the project up to 2 GB free for the entire team. All art assets and documents can be kept here and it is very secure.

Teamspeak: www.teamspeak.com

Client and server download click this link:

Teamspeak is a great way to have a permanent conference call line open for your team. You can host your own server for free and all use of the clients are free.

Join Me: Joinme.com

Join Me is a screen sharing system which is great for meetings and demonstrations to the team. This will allow you to show documents that are being worked on and also show anything else to your team.

Bitbucket: Bitbucket.org

This is a free source control site that will allow you to share code to all the teams developers. Using this site will stop you from having to constantly send files back and forth while they get updated from your dev team. They also allow free private source control.

SourceTree: Sourcetreeapp.com

A free source control application that you will need to use to link to your bitbucket account. This will allow each developer to pull, push, and commit code. Also it will keep individual users from over righting each others code by managing it for them.

Using these tools will allow proper management of your team and keep people on track. With use of or Game Dev Agile Approach you can make the development of the game more like a competition than like actual work.

If you have any questions please feel free to comment!

2

It looks to me like you’ve almost just applied some agile elements to a waterfall approach. Really if you want to be efficient and truly agile, you should be tasking everything out so early. What you should be doing instead is, as a stakeholder, building out your backlog. You create PBIs (product backlog items) such that they are recognizable units of work, can be prioritized, and represent a portion of the project which will provide “business value” upon completion (i.e. in most cases something you can demonstrate even if it is in a rough form). You’ll want to prioritize these before pointing.

Rather than pointing the tasks, you point the PBIs (also known as User Stories). The pointing system should be as follows:
1, 2, 3, 5, 8, 13, 100.

You can use zero and 1/2 as well but I don’t generally find those to be useful. Also, the reason for those specific point numbers is that they are Fibonacci numbers. When pointing, if you get something as large as a 13, then you should probably consider splitting it into more than one user story. If you have a 100, that’s considered an Epic and means that it will require a significant investment in research, development, and will most certainly be split into multiple user stories.

Once you have your user stories pointed, then you can decide how many to bring into your current sprint… this should be done as a team as well and as a product owner you will need to continually working on building out and grooming the backlog. You also won’t want to point user stories too far ahead as you’ll adjust as you go forward.

Now as a team you’ll bring each user story (PBI) into the sprint one at a time in priority order and task it out. At the early stages you’ll probably want to use hourly estimates to determine capacity but as you get more accurate in your pointing you can determine how many stories will fit into a sprint based on availability of your developers.

Once the PBI is split into tasks, you then you assign an estimated number of hours to complete each task. Then your developers work those tasks and make sure they are burning down the hours as they go. This allows you to track velocity and to know whether you are on track to complete the sprint or whether alarm bells should be raised and you should check for impediments.

Also, the “meetings” are generally called Ceremonies in agile. Don’t ask me why, it’s purely symantic. You also should add some additional ceremonies (daily standup for quick updates as well as checking for impediments and retrospective to allow the team to discuss what went well during the sprint… which can be done in a number of formats including Well / Not Well or Start/Stop/Continue Doing).

I work in a professional scrum environment and have been a part of several teams that all implement it a little differently depending on the team and needs so if you have any questions I’d be happy to answer them.

Last but not least, you should add Pointing Poker to your list of tools… there’s a free website for it and it’s pretty easy to use and invaluable to us as we use it for our pointing and Retrospectives:

1 Like
3

That’s some pretty good insight. I actually work as a Automated QA myself in a scrum environment. However, the team I work with for game development has never worked in scrum before and I decided to create a watered down version that they would more easily understand. When my team grows I plan to move them into something that more closely resembles what you’re describing.

Thanks for adding greater detail!

4

I’d like to add something else to this. Gathering customer feedback is what game developers should be doing alongside with team management. Game developers must position themselves early on around their customers (those who will play their games). You may even wish to build a knowledge base to answer frequently asked questions raised by your users.

This is why Helprace came up with a community portal and a helpdesk request ticketing in one platform. Why wait for your team to grow? It’s easy and free to start using something like this, and the fruits of your labour will be apparent only after you start growing. At least you know you’ll be growing in the right direction.

1 Like
5

That’s very true! Thanks for the helpful advice!