Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Squeaky Wheel cofounder Ryan Sumo describes his process for project management of remote teams.
The current situation with the covid-19 coronavirus has opened up a general conversation about the future of work and working from home. Squeaky Wheel has been essentially working from home since it started, only meeting twice a month for some face to face interactions and team bonding time. Because of this, the imposition of the Metro Manila lockdown has not created major changes in how we run our team.
What I will be sharing here are some specific details about how we run our development team of 5 (I’m not including our CFO who handles all the bank and payroll transactions for us since that would make this too long) while working on Academia : School Simulator. While some of this may mostly be useful for similar sized teams working in game development, I’m hopeful there are lessons that larger teams or those in different fields can pick up and adapt to their own purposes.
If there is only one thing you will take away from this is that you need to assign a producer role to someone on your team. Producers are much maligned in the game industry as people who don’t really “do anything” yet manage the people who actually “do the work”.
When Squeaky Wheel started out we had this mindset. We would set tasks for ourselves and then just work separately throughout the week. It was a recipe for a lot of wasted effort as we often not working in sync, with designs being made months before they needed to be implemented, and mechanics that were being implemented lacking design. It created a lot of mental stress for me, and the only reason we managed to keep going was that each individual was working hard as hell, including sometimes on weekends.
After taking on the role of producer myself, we’ve managed to make it so that we mostly work in sync and no longer work on weekends because we’re much more efficient about how we do things.
This belies a lot of “invisible labor” by the producer, who must navigate the fine line between knowing what is happening in the team and if we’re on schedule versus simply micromanaging everything. Think of the producer as a director, a symphony conductor, or a basketball coach. Their role is to try to make sure that everyone is in sync for the betterment of the whole team.
Ideally you would have a full time producer, but if not, one of the team members needs to step up and really embrace this role.
While this blog will cover what the week to week management of a team looks like, ultimately none of this works unless you all know what you’re aiming for. For Squeaky Wheel, what we’ve been doing is breaking our development up into milestones.
Here is what our milestone for “Alpha 4” looks like, which I can share with you since we are nearing the end of this milestone. I won’t go into too much detail about how we arrived at these mechanics and time estimates since that would take up an entire article of its own.
But here are the basics of making your own milestone timeline:
Decide what mechanics you want to add to the game (this is its own complicated process unless you have a genius designer/producer that holds all decision making power)
Ask for time estimates for each mechanic (rule of thumb, whatever your team says, assume they are overconfident and add a day or two).
The producer then arranges the milestones into scheduled updates, trying to make sure that there is just enough work to be done for each update. For our case, since Alpha 4 milestone started, we’ve been organizing these updates into “themed updates”. We try to have at least one key mechanic or a series of related mechanics to anchor the update.
Then after that, everything goes fine and you just work till you complete the milestone.
Haha just kidding.
Throughout development the producer needs to keep an eye on this timeline, checking in at the end of every sprint to see how far along the team is with their work, and if anything needs to be adjusted. You’ll notice that there are quite a few mechanics that have a delayed marker next to them. Depending on the situation, these mechanics have either been delayed for future updates or the team has decided they’re no longer necessary. There will also be times, especially if you’re in Early Access, that you will realize that certain mechanics must be added that you didn’t account for. That is where it is crucial to have a producer that can discuss these issues with the team and make the necessary changes to the schedule.
Each themed update is broken down into sprints. Sprints have a very specific definition in Agile methodology, but we’ve taken what we need from it and are adapting it to our needs (as you should do with these suggestions).
Sprint and update length should be decided by the producer, depending on the needs and capacity of the team. As for Squeaky Wheel, over time we found that the one week sprints we were doing were far too short to allow enough breathing room in between working on bugs and working on new mechanics.
Similarly, our updates used to be spaced at one month intervals. This was necessary early on in Early Access to give players the sense of continuous development. However as we built trust with our community, we decided to announce to the players that we would be releasing updates every other month instead, and it’s been much less stressful for us overall. To review, our previous work schedule was 4 one week sprints per month, whereas now it’s 3 two week sprints per one and a half months.
Each sprint begins in the previous sprint with a sprint review which is done via Flock (more on that later). I allot myself one day at the end of each two week sprint to chat individually with each team member about how work is going. I will review tasks that are unfinished or pending. I will ask if there Is there anything slowing them down, anything they want to discuss, etc. I will then assign them new tasks on HacknPlan (more on that later) based on the schedule and their available time.
This is where the time estimates you made previously come in handy. While this is not a hard science, ideally we make our estimates in days, as in “it will take me x days to complete this task”. Since we have two week sprints, that means we have 10 workdays in each sprint. Basically the sprint review is the producer playing time management tetris for each team member, allocating them enough estimated work for 10 days.
The producer needs to allocate time for unexpected occurrences. For example since our game is in Early Access and is actively in development, bugs reports come in on almost a daily basis. So for our programmers I make sure to allot time for 8 days worth of work, assuming that 2 days will be taken up with bugfixing. Our lead designer has also been tasked with community management, so I allocate 1 day for that across the entire sprint, assuming he will spend at least an hour per day doing that (we assume 8 hours = 1 day).
It is important that the sprint review be done before the start of the next sprint so that everyone is ready to begin on their tasks. This works for our dev team of 5, and depending on how good your team and your producer are, it may scale up to 10 people. Beyond that you would likely need to organize in such a way that there are lead programmers/designers etc who handle the people under them while the producer coordinates with the leads.
The start of each sprint is where we typically do our actual face to face meetings. We reserve space at a coworking space and meet there for the day to discuss any major issues that can be more easily facilitated through face to face interactions. We also have lunch and sometimes dinner and boardgames together for team building and morale boosting.
Since we’ve decided to cancel even these once a week meetings, we’ll start doing these discussions on Flock as well. For easy dissemination, almost all our documents are now in the cloud using Google Docs, so everyone can look at the doc while we are discussing the topic at hand.
During a regular day, we start things off by announcing to the team what we’re working on for the day. This allows the producer to see if everything is in sync, and if not, communicate directly with the team member that they should start working on something else instead. This process repeats until the team gets to the end of each sprint, then the end of the update, where we release a new update of our game to the world.
Looking back on what I wrote, it actually seems like all of the stuff I mentioned above could just as easily be done in a real life office. It’s just that in a real office you can kind of compensate for any misjudgements by running from one person to the next and plugging in holes. I don’t claim for this to be the best way to work completely online, but it is what has worked for us. I hope it helps you, and if you have any suggestions about how we could do things better please drop us a line!
These are tools we use to work online which did not fit neatly into the structure of the article above. I wrote a previous article about this before which may have more useful information.
Once again this deserves its own post so I won’t deep dive into this topic. But as a frame of reference the project management tool we use is called HacknPlan. It is specifically made for game developers, and I have found it very useful for our needs. We used to use Trello, then JIRA, both of which many people use to manage their teams. However for our purposes I found that HacknPlan is the easiest tool to simply jump in and start project management for game development, whereas the other tools would need a lot more tweaking.
I plan on writing about online communications with Flock at some point, but here are some basics. Make sure you have designated channels for different disciplines, and for major mechanics. This makes it less confusing when everyone is chatting at the same time so that you know what you’re talking about. Never assume that the other person you are talking to knows what you are thinking. Whereas in real life we can point to someone’s screen and make hand gestures so they know what we’re talking about, communicating with text requires extra thought. Flock has tools like video calls but we tend not to use those because of low bandwidth.
We use Rescuetime to monitor our personal work use, but we don’t use it to monitor employee work time (I’m personally uncomfortable with doing that). But it can do that if that’s how you want to manage your team.
All our documentation is now on Google Docs. This makes it instantly shareable, and we can easily comment on parts of the document that are unclear to us.
(this section written by our lead programmer Marnel. For more of his insights, read his blog)
For version control, we're using Git hosted at Bitbucket. We use Sourcetree as our Git client as we are not really good with the command line, even the programmers. As for managing the branches, we have a main branch called "develop" where commit/push rights is only granted to Marnel. To make changes, other team members are required to create a separate branch which is named after the task ID based from HackNPlan. These branches are branched from the latest from develop. When the task is marked for code review or for merging, Marnel reviews the changes in the branch and merge them if they are safe. If not, the task is returned to the owner for further revisions. This is repeated until the branch is merged.
We also manage other branches like release and hotfix. The "release" branch is used by Unity Cloud Build. Sometimes the develop already have changes that are not meant to be released yet. This is why a separate release branch is used. This is also the reason for hotfix branch.
Thanks for reading, and hope you found this interesting! If you want to support us, you can buy Academia: School Simulator or Political Animals, or wishlist Ruinarch.
Read more about:
Featured BlogsYou May Also Like
