Plan for Stephen Zepp
by Stephen Zepp · 02/21/2005 (7:50 pm) · 4 comments
This topic has been touched upon by a lot of people, including some very good insights by Josh Dallman, but I wanted to try to give a comprehensive case study of how our project is organized and managed, and several of the benefits and disadvantages of how we are doing business currently. By the way, no screen shots in this one--sorry!
Background
Our team has it's roots in a lore-based Shadowbane guild on the Fear server called the "Church of the Reunification". The original team members were all avid PvP players, but not interested in FPS games--and we really thought that we had a winner in the early days of Shadowbane, bugs and all. The driving difference between our guild and the majority of players however was the fact that we were strongly lore-based, and felt that it enhanced the game experience. Without making this a rant about the failures of Shadowbane's approach to lore and game mechanics, we stopped playing and starting playing around with the idea of designing our perfect game. The one we wanted to play.
Communicating Virtually
Needless to say, there are huge advantages to being able to meet in the same room and discuss design issues. Most Indy teams however don't have this luxury, and instead have to meet their communication needs in the 'net. We've found that virtual communication is both our biggest strength, and our biggest weakness.
Forums: Our primary means of communication is an organized set of forum areas that are broken down into major functional areas: Design, Implementation, Art Assets, Audio Assets, Background Lore, Production/Project Management, and General discussion/brainstorming.
Strengths
--Every single communication exchange is permanent, and can be reviewed at any time. We don't have to worry about ideas literally disappearing because someone forgot to take notes of a conference call, or lost track of specific details of an implementation decision.
--People have time to consider other's ideas in a relaxed manner, and really think about how specific ideas affect the whole of the project. Posts vary from completely random brainstorming to pages long discussions with a week's prep time by the author.
--With good moderation/post administration, designs and ideas can be cross-linked to other posts to highlight concepts and parallels in design, as well as re-aligned with original posts when required to keep things from proceeding too far from the original vision.
Weaknesses
--Progress can be slow. While I literally live on the forums as much as I can, others cannot necessarily keep the same focus, and it may take weeks for specific concepts and designs to be fleshed out if a key member of the discussion isn't able to participate often.
--It can be very difficult to correctly state an idea or a concept, and a week's worth of discussion and design sometimes goes down the drain when everyone realizes what the original poster really meant. Some people simply don't express themselves well in a written style (not a weakness, just a fact), and those people tend to have their ideas overwhelmed by other, more forceful posters.
--Since the forums are the primary focus for most of the team, when forum traffic is slow, the team tends to lose focus. Since it's a solo act to read and respond, many times members will do a quick scan of the forums and see if there are any active discussions, and if not, go on to other real life tasks (not project related), instead of using free time on the project itself. This is especially apparent when those that normally drive discussions (not just me) are caught up in real life and cannot post as often as normal for a few weeks. We've literally had a month or two go by with no post traffic, and it can be very hard to keep people focused and motivated during these periods.
Instant Messaging: Another form of communication we use, especially when implementing functionality is instant messaging. It is an excellent method for rapid give and take discussion to work through bugs, implementation issues, and brainstorming.
Strengths
--if both/all parties are online, you have pretty much instant communication.
--takes up much less screen space when actively developing/testing.
Weaknesses
--while you can cut/paste sessions, it isn't very appealing as a permanent record of discussions.
--it can be quite a distraction when one team member is hard at work on a task, and another wants help on a different task, or simply feels like chatting. I personally hate like hell to do it, but I've had to log off AIM if I was working through a particularly difficult implementation issue and was being distracted by AIM.
Email
As a third communication tool, we sometimes use normal email to discuss involved issues, especially if large log files or debugger stacks are involved.
Strengths
--can blast a ton of information to a specific target without distracting/bothering others in the forum area. Especially good for working through troubleshooting/debugging.
--sometimes a team member doesn't have the ability to access forums/AIM (at work, for example), but can respond to emails with little difficulty.
Weaknesses
--If used too regularly, you lose the organization and permanence of the forums, as well as the ability to catch someone up to speed on a particular issue.
--too much reliance can force people out of the loop when they may have strong contributions to give
Personnel Management
Without a doubt, the most difficult challenge for me has been keeping team members focused and motivated. You simply don't have the face to face contact that a brick and mortar team has, and this means that it is extremely easy for individual team members to "swiftly and silently slip away"--either for an extended period, or forever. Even our most motivated team members (myself included, for sure) can easily lose track of the project's momentum due to real life, and without the face to face contact, it is extremely difficult to identify and try to alleviate individual team member's issues and concerns. For reference, we currently have a team of 9 active members: 1 Producer, 1 Lead Dev (with me assisting as a Dev when needed), 1 Dev, 3 Designers (with responsibilities ranging from background research to game systems design to handling whatever other tasks come up), 1 QA Lead who is in the process of taking on Assistant Producer roles as well database design, 1 Audio Engineer, 1 "Jack of All Trades Artist", and a combined 2-D artist/db admin/dev in training.
That doesn't sound so bad, until you analyze our churn rate: Over the last 8 months, I've brought in 13 other prospective team members that have all dropped out for various reasons. We've had Assistant Producers, Tech Writers, Artists, Designers, multiple Devs (including TWO Mac devs that we've lost, and that hurts bad!), the works--and lost them all. This is the most critical failure in our project to date.
I know that some are thinking right now, "What the hell is he thinking? 21 member team? Who does he recruit--anyone that can create an account on the forums?". Ironically, the recruitment process normally lasts weeks, averaging a dozen or so email exchanges of quite lengthy discussions, and prospective team members are vetted heavily with regards to their personal motivations for joining us, their personal goals and wants, their satisfaction criteria, their skillset(s), and both TGE and general software development experience. By the time I'm ready to bring someone "into the circle", they've met every single thing I can think of that a dedicated and motivated team member should have. Obviously, I don't have it figured out yet!
Maintaining Member Motivation
This one is extremely difficult as well. I myself have had extensive periods (months, in fact), where I couldn't even handle the thought of logging in to check the forums, much less sit down to the keyboard and refactor the dozen or so vision documents with the latest from the forums. One thing I have learned is that in this type of team environment, you must expect, and factor in to your milestone timelines, the fact that most of your team is going to work in spurts--sometimes a month of extreme motivation and product, followed by weeks to months of being almost invisible. Without a salary, or even small payments of whatever sort, it's very difficult to even blame anyone for that type of stop and start productivity.
Finding a way to keep all of your team motivated is just about impossible, but here are some of the things I've learned:
--find out, and keep finding out, what keeps each member involved. For some, it's simply the wonder of being a part of a team making a game. For some, it's the satisfaction of accomplishing tasks (especially nice for the implementers). For some, it's the potential of being part of something that could really make it big (or not!), and the challenge of sticking it out to reach that point. Whatever each team member's motivation is, when you manage a virtual team, you need to find out what makes each member tick, and focus on that.
--balance what needs to be done against what your team members want to do. You can't always win in this situation, but don't stick your database guy, even if he is the most skilled at db design in the team, doing what he spends 8-12 hours at work every day doing. That just makes him have to go from work to more work, and he probably isn't going to hang for very long. Also, make sure your developers (coders) are working on things that they find exciting and challenging--but, balance that against what needs to be done as well. Sometimes the boring stuff simply has to be done, and someone has to do it.
--don't take too much on yourself, and don't overload anyone either--they (or you) will just slip away. Quite frankly, Joshua Dallman is my role model here--he has the skills to do a wide variety of tasks for his project, but instead, is keeping his focus on Project/Team management--and look at the success of his project so far. I find myself doing everything from design documentation to team discussion lead on the forums to implementing major systems, all the while trying to balance market research, corporate development/strategy, project milestone management, staying an active community member here at GG, plus (currently) doing on-site contract work at a hospital. It simply becomes too much if you try to do everything, and everything suffers. This is something I must fix if NemV is to continue on the path we've chosen.
This plan has already grown larger than I'd expected, and I've not nearly covered everything I wanted to, but I'm going to wrap it up with a summary of how I think we are doing, listing the top three in each category:
What we are doing right
--Maintaining our Vision: I've discussed this elsewhere, but we are staying true to what we really want to do. In and of itself I think this is why we've been successful so far.
--Keeping ourselves positively challenged: We're continuing to press ourselves towards increasing the skills we need to accomplish our goals by using a customized project methodology based on agile software development. This lets us demonstrate game functionality at our current skill set, without limiting specific systems implementation based on what we don't know at the time. We factor in this expected lack of knowledge by planned re-writes of major systems staggered across our milestones--this lets us revisit systems in the future with a broader experience and knowledge set.
--staying focused, but not locked in to the small view: We constantly evaluate what we are doing in a specific task to make sure it stays in line with our focus. For example, we elected to ditch our MySQL implementation for a PostGreSQL database structure because we found that while MySQL met our current needs, it wouldn't meet our needs 6-9 months down the road. We also ditched some limiting implementations when we discovered alternative toolsets--instead of forcing terrain tiling into TGE, we've elected to move to TSE in the very near future.
What we need to do better
--Team Motivation: Every team needs to keep this as a primary goal, and I know that we need to do this better to keep our very skilled members motivated. I've lost way too many skilled members, and need to figure this out.
--Churn planning: Churn will never go away, and while I hope to minimize it, I'm also "cross-training" team members to fill in roles that may come open in the future. For example, I have an extremely talented and experienced QA member, but since the highest priority right now is Producer related tasks, I'm cross-training him to meet that need. Unfortunately, this takes him away from the critical QA role, and I can't afford to burn him out by overload--which is way too easy to do.
--Communication: Even with the multiple channels I described above, we still have communication issues. I have a personal block about using voice communications, but even after 3 years of avoiding TeamSpeak, I need to get over it and get the team using some form of periodic voice comms--even if it's just for status meetings.
Background
Our team has it's roots in a lore-based Shadowbane guild on the Fear server called the "Church of the Reunification". The original team members were all avid PvP players, but not interested in FPS games--and we really thought that we had a winner in the early days of Shadowbane, bugs and all. The driving difference between our guild and the majority of players however was the fact that we were strongly lore-based, and felt that it enhanced the game experience. Without making this a rant about the failures of Shadowbane's approach to lore and game mechanics, we stopped playing and starting playing around with the idea of designing our perfect game. The one we wanted to play.
Communicating Virtually
Needless to say, there are huge advantages to being able to meet in the same room and discuss design issues. Most Indy teams however don't have this luxury, and instead have to meet their communication needs in the 'net. We've found that virtual communication is both our biggest strength, and our biggest weakness.
Forums: Our primary means of communication is an organized set of forum areas that are broken down into major functional areas: Design, Implementation, Art Assets, Audio Assets, Background Lore, Production/Project Management, and General discussion/brainstorming.
Strengths
--Every single communication exchange is permanent, and can be reviewed at any time. We don't have to worry about ideas literally disappearing because someone forgot to take notes of a conference call, or lost track of specific details of an implementation decision.
--People have time to consider other's ideas in a relaxed manner, and really think about how specific ideas affect the whole of the project. Posts vary from completely random brainstorming to pages long discussions with a week's prep time by the author.
--With good moderation/post administration, designs and ideas can be cross-linked to other posts to highlight concepts and parallels in design, as well as re-aligned with original posts when required to keep things from proceeding too far from the original vision.
Weaknesses
--Progress can be slow. While I literally live on the forums as much as I can, others cannot necessarily keep the same focus, and it may take weeks for specific concepts and designs to be fleshed out if a key member of the discussion isn't able to participate often.
--It can be very difficult to correctly state an idea or a concept, and a week's worth of discussion and design sometimes goes down the drain when everyone realizes what the original poster really meant. Some people simply don't express themselves well in a written style (not a weakness, just a fact), and those people tend to have their ideas overwhelmed by other, more forceful posters.
--Since the forums are the primary focus for most of the team, when forum traffic is slow, the team tends to lose focus. Since it's a solo act to read and respond, many times members will do a quick scan of the forums and see if there are any active discussions, and if not, go on to other real life tasks (not project related), instead of using free time on the project itself. This is especially apparent when those that normally drive discussions (not just me) are caught up in real life and cannot post as often as normal for a few weeks. We've literally had a month or two go by with no post traffic, and it can be very hard to keep people focused and motivated during these periods.
Instant Messaging: Another form of communication we use, especially when implementing functionality is instant messaging. It is an excellent method for rapid give and take discussion to work through bugs, implementation issues, and brainstorming.
Strengths
--if both/all parties are online, you have pretty much instant communication.
--takes up much less screen space when actively developing/testing.
Weaknesses
--while you can cut/paste sessions, it isn't very appealing as a permanent record of discussions.
--it can be quite a distraction when one team member is hard at work on a task, and another wants help on a different task, or simply feels like chatting. I personally hate like hell to do it, but I've had to log off AIM if I was working through a particularly difficult implementation issue and was being distracted by AIM.
As a third communication tool, we sometimes use normal email to discuss involved issues, especially if large log files or debugger stacks are involved.
Strengths
--can blast a ton of information to a specific target without distracting/bothering others in the forum area. Especially good for working through troubleshooting/debugging.
--sometimes a team member doesn't have the ability to access forums/AIM (at work, for example), but can respond to emails with little difficulty.
Weaknesses
--If used too regularly, you lose the organization and permanence of the forums, as well as the ability to catch someone up to speed on a particular issue.
--too much reliance can force people out of the loop when they may have strong contributions to give
Personnel Management
Without a doubt, the most difficult challenge for me has been keeping team members focused and motivated. You simply don't have the face to face contact that a brick and mortar team has, and this means that it is extremely easy for individual team members to "swiftly and silently slip away"--either for an extended period, or forever. Even our most motivated team members (myself included, for sure) can easily lose track of the project's momentum due to real life, and without the face to face contact, it is extremely difficult to identify and try to alleviate individual team member's issues and concerns. For reference, we currently have a team of 9 active members: 1 Producer, 1 Lead Dev (with me assisting as a Dev when needed), 1 Dev, 3 Designers (with responsibilities ranging from background research to game systems design to handling whatever other tasks come up), 1 QA Lead who is in the process of taking on Assistant Producer roles as well database design, 1 Audio Engineer, 1 "Jack of All Trades Artist", and a combined 2-D artist/db admin/dev in training.
That doesn't sound so bad, until you analyze our churn rate: Over the last 8 months, I've brought in 13 other prospective team members that have all dropped out for various reasons. We've had Assistant Producers, Tech Writers, Artists, Designers, multiple Devs (including TWO Mac devs that we've lost, and that hurts bad!), the works--and lost them all. This is the most critical failure in our project to date.
I know that some are thinking right now, "What the hell is he thinking? 21 member team? Who does he recruit--anyone that can create an account on the forums?". Ironically, the recruitment process normally lasts weeks, averaging a dozen or so email exchanges of quite lengthy discussions, and prospective team members are vetted heavily with regards to their personal motivations for joining us, their personal goals and wants, their satisfaction criteria, their skillset(s), and both TGE and general software development experience. By the time I'm ready to bring someone "into the circle", they've met every single thing I can think of that a dedicated and motivated team member should have. Obviously, I don't have it figured out yet!
Maintaining Member Motivation
This one is extremely difficult as well. I myself have had extensive periods (months, in fact), where I couldn't even handle the thought of logging in to check the forums, much less sit down to the keyboard and refactor the dozen or so vision documents with the latest from the forums. One thing I have learned is that in this type of team environment, you must expect, and factor in to your milestone timelines, the fact that most of your team is going to work in spurts--sometimes a month of extreme motivation and product, followed by weeks to months of being almost invisible. Without a salary, or even small payments of whatever sort, it's very difficult to even blame anyone for that type of stop and start productivity.
Finding a way to keep all of your team motivated is just about impossible, but here are some of the things I've learned:
--find out, and keep finding out, what keeps each member involved. For some, it's simply the wonder of being a part of a team making a game. For some, it's the satisfaction of accomplishing tasks (especially nice for the implementers). For some, it's the potential of being part of something that could really make it big (or not!), and the challenge of sticking it out to reach that point. Whatever each team member's motivation is, when you manage a virtual team, you need to find out what makes each member tick, and focus on that.
--balance what needs to be done against what your team members want to do. You can't always win in this situation, but don't stick your database guy, even if he is the most skilled at db design in the team, doing what he spends 8-12 hours at work every day doing. That just makes him have to go from work to more work, and he probably isn't going to hang for very long. Also, make sure your developers (coders) are working on things that they find exciting and challenging--but, balance that against what needs to be done as well. Sometimes the boring stuff simply has to be done, and someone has to do it.
--don't take too much on yourself, and don't overload anyone either--they (or you) will just slip away. Quite frankly, Joshua Dallman is my role model here--he has the skills to do a wide variety of tasks for his project, but instead, is keeping his focus on Project/Team management--and look at the success of his project so far. I find myself doing everything from design documentation to team discussion lead on the forums to implementing major systems, all the while trying to balance market research, corporate development/strategy, project milestone management, staying an active community member here at GG, plus (currently) doing on-site contract work at a hospital. It simply becomes too much if you try to do everything, and everything suffers. This is something I must fix if NemV is to continue on the path we've chosen.
This plan has already grown larger than I'd expected, and I've not nearly covered everything I wanted to, but I'm going to wrap it up with a summary of how I think we are doing, listing the top three in each category:
What we are doing right
--Maintaining our Vision: I've discussed this elsewhere, but we are staying true to what we really want to do. In and of itself I think this is why we've been successful so far.
--Keeping ourselves positively challenged: We're continuing to press ourselves towards increasing the skills we need to accomplish our goals by using a customized project methodology based on agile software development. This lets us demonstrate game functionality at our current skill set, without limiting specific systems implementation based on what we don't know at the time. We factor in this expected lack of knowledge by planned re-writes of major systems staggered across our milestones--this lets us revisit systems in the future with a broader experience and knowledge set.
--staying focused, but not locked in to the small view: We constantly evaluate what we are doing in a specific task to make sure it stays in line with our focus. For example, we elected to ditch our MySQL implementation for a PostGreSQL database structure because we found that while MySQL met our current needs, it wouldn't meet our needs 6-9 months down the road. We also ditched some limiting implementations when we discovered alternative toolsets--instead of forcing terrain tiling into TGE, we've elected to move to TSE in the very near future.
What we need to do better
--Team Motivation: Every team needs to keep this as a primary goal, and I know that we need to do this better to keep our very skilled members motivated. I've lost way too many skilled members, and need to figure this out.
--Churn planning: Churn will never go away, and while I hope to minimize it, I'm also "cross-training" team members to fill in roles that may come open in the future. For example, I have an extremely talented and experienced QA member, but since the highest priority right now is Producer related tasks, I'm cross-training him to meet that need. Unfortunately, this takes him away from the critical QA role, and I can't afford to burn him out by overload--which is way too easy to do.
--Communication: Even with the multiple channels I described above, we still have communication issues. I have a personal block about using voice communications, but even after 3 years of avoiding TeamSpeak, I need to get over it and get the team using some form of periodic voice comms--even if it's just for status meetings.
About the author
#2
02/21/2005 (10:28 pm)
There's definitely a lot to team development and you've given some good insight here into a larger team (maybe too large). Mix some of these things with some of Joshua Dallman's pointers and I think you've got a winning stategy though.
#3
Stephen: Maybe try wiki.. theyre wickedly good at design kind of discussions.
02/22/2005 (1:07 am)
7 Months?? Damn you to Hell Matt for letting me know that!!! Damn damn damn! :)Stephen: Maybe try wiki.. theyre wickedly good at design kind of discussions.
#4
It can be very hard to manage, and this is with professional businesses who deal internationally all the time.
Deadlines and milestones play a very big part of it, setting realsitic targets and having some flexibility is paramount, as any dev knows, it does not always go according to plan.
A good toolset to manage a project is important, I use email, instant messaging and the phone to keep in touch. VPN and remote access let me jump in where needed.
Of course dealing with volunteers is going to add a an extra level of complexity. RealLife(tm) intrudes, babies get born, puppies teethe their way through cables (or is that just mine? :-), bikes get crashed (it hurts) etc...
I would look at eGroupware, it has a project manager, wiki, forum, trouble tickets, email, file manager and a bunch of other stuff. But no tool will help if it isnt used. It requires a certain amount of discipline on everyones part. Blogging may be a good one, if agreed upon updates are adheared to, to allow members to update each other.
Some method of showing everyone that progress is being made is vital, and whoever is managing the project should stick to a regular update, highlighting progress (with a virtual pat on the back) will definately help team members see that they are part of an ongoing progressing project. Set regular'ish (timezones make this a bit of a pain) meetings, IM is great for this or maybe Skype.
Sounds like you have a good handle on things though, good luck.
02/22/2005 (8:02 am)
Well, I manage projects for a living, and the people who work on them are in places like Finland, Germany, Denmark, Italy and the UK.It can be very hard to manage, and this is with professional businesses who deal internationally all the time.
Deadlines and milestones play a very big part of it, setting realsitic targets and having some flexibility is paramount, as any dev knows, it does not always go according to plan.
A good toolset to manage a project is important, I use email, instant messaging and the phone to keep in touch. VPN and remote access let me jump in where needed.
Of course dealing with volunteers is going to add a an extra level of complexity. RealLife(tm) intrudes, babies get born, puppies teethe their way through cables (or is that just mine? :-), bikes get crashed (it hurts) etc...
I would look at eGroupware, it has a project manager, wiki, forum, trouble tickets, email, file manager and a bunch of other stuff. But no tool will help if it isnt used. It requires a certain amount of discipline on everyones part. Blogging may be a good one, if agreed upon updates are adheared to, to allow members to update each other.
Some method of showing everyone that progress is being made is vital, and whoever is managing the project should stick to a regular update, highlighting progress (with a virtual pat on the back) will definately help team members see that they are part of an ongoing progressing project. Set regular'ish (timezones make this a bit of a pain) meetings, IM is great for this or maybe Skype.
Sounds like you have a good handle on things though, good luck.
Associate Matt Fairfax
PopCap