Distributed Work Environment. We integrated remote workers onto our team, and the integration accelerated our development tremendously. We recruited online students from all over the country and they put in twice as much work as our on-ground team in two thirds of the time! Some of our distributed team members have reached out to us asking if they could continue working on the project without being enrolled in the course next semester.

Technology. We were able to set up our team with the tools that they needed to succeed. We set up a couple private channels on our game studio Slack and the channel enabled us to work with our distributed team. We also set up a slack channel specifically for our junior programmers to ask programming questions and they made good use of the channel to solve programming problems quickly. We had minimal version control issues since only team leads and programmers had permission to make commits to the subversion repository.

Unity 5 UI Tools. Unity's new user interface tools made developing a good UI for the game a breeze. I was able to throw together a rough prototype health/oxygen script with a good looking UI after 5 minutes of work. This rough prototype served as our UI for most of the builds of the semester until the designers and artists could begin tweaking the pacing of oxygen loss and the look of the interface.

The Greenlight Celebration. This semester's greenlight celebration was the largest and most useful I've seen yet.  It was so good that I dedicated an entire blog post to the greenlight pitches and celebration. We were able to get an early build of our game in front of an audience and see how people played our game. We were surprised to discover that our game was interesting to younger children and received some great feedback we intend to incorporate in our next release.

A Slow Start. We got off to a slow start at the beginning of the semester. We didn't have a working prototype yet when we got started, we lost our first week of work to a holiday and our second week of development was mostly focused on getting the new recruits up to speed, so development of the game didn't truly get underway until we were three weeks into the semester. Our remote team members also got off to a slow start because they spent their first week of work getting up to speed on the project.

Communication. We lost some time due to a couple of miscommunications between our on-ground team and our remote workers. A few tickets were poorly described and we had remote workers work on the wrong task as a result. The other communication problem we ran into is that on ground students aren't as responsive as our remote students. We had a couple of our remote developers go two or three days without getting an important question they needed answered so they could continue their work and we lost some velocity as a result.

Last Minute Builds. Unlike on my last project, just about every build we presented at a build review came together at the absolute last possible moment and not every feature that had been worked on had time to be tested and implemented into the build for the week. For our next semester of development we've decided to set aside a day of the week that everyone must submit their work to be reviewed and implemented into a build to be presented at the next build review.

Team Make Up. We were starved for artists this semester. We had two artists in the on ground team, an art contractor here, and one remote artist. Our on ground team was still early in their degree program and hadn't yet learned how to unwrap and texture models. On the flipside, we had more programmers than we needed and we started running out of work for them to do at the end of the semester. Having too many of one discipline can be almost as bad as not having enough because we had to keep generating new tasks for them to work on that were outside of the scope of our release for the semester.