1

Case Study: Overcoming Challenges in Game Capstone Course

Nelson Man
IS4600 Software Project Management

2

Table of Contents
Introduction ..................................................................................................................................... 3
Getting Started ................................................................................................................................ 3
First Challenge the Team Faced ..................................................................................................... 4
Our Workflow ................................................................................................................................. 4
Establishing Our First Requirements .............................................................................................. 6
Additional Challenges the Team Faced .......................................................................................... 6
New Additions to the Team: The Sound Team .............................................................................. 7
Advantages of Working in a Virtual Team ................................................................................. 7
Disadvantages of Working in a Virtual Team ............................................................................. 8
Even More Challenges the Team Faced ......................................................................................... 8
Things That Worked Well .............................................................................................................. 9
Things That Did Not Work Well .................................................................................................. 10
How We Should Adapt Next Time ........................................................................................... 11
Conclusion .................................................................................................................................... 12
Appendix 1: Project Schedule ....................................................................................................... 12


3

Introduction
The purpose of the Game Capstone class is to give students a chance to create a game.
Students form their own teams and work together to create a shippable product by the end of the
semester. The intended goal of the class is to have students experience working together in
multidisciplinary teams and have a game they can put in their portfolios. The design, scope, and
workflow of each team are completely left to the students. The professor is mainly there as a
facilitator for team conflicts that could not be resolved by the teams themselves and as an aid to
students in removing blockages in work. The students grades are not determined by the quality
of the end product, but how well the students worked together as a team, the teams work
process, and the other team members assessments of how each team member contributed.
Getting Started
Since the Spring semester of the Game Capstone class is a continuation of the Fall
semesters course, students were given time at the end of the Fall semester to form our teams for
the Spring semester. My team came together before Winter break and consisted of three
programmers, an artist, and a producer. We met before the end of the Fall semester, and we
decided to brainstorm ideas for a game over Winter break, as well as meeting as early as possible
in the Spring semester.
We met again on the first day of the Spring semester to discuss our ideas and goals for
the game. We all agreed that we wanted to work on a small, multiplayer, party game, because
none of us had ever made a multiplayer game. We also agreed that rather than having a game
with a lot of features, it would be better to have game with less features, but a more polished
look and feel. This meant that the scope of our game would be small. After throwing around a
4

few ideas, we decided on creating a game multiplayer, party game with a top-down view that
involved shooting one another in an arena (similar to Wii Tanks). By the end of this initial
meeting we had a set of unambiguous goals, and a more certain idea of the requirements.
First Challenge the Team Faced
The first challenge our team faced occurred when our most experienced developer left the
team. Since it was the beginning of the semester, the teams were not officially cemented in place
yet. He felt that another one of the teams was a better fit for him and left to join that group. To
mitigate the ramifications this would have on our project, we met as soon as possible to discuss
our course of action.
With our most experienced developer gone, we had two programmers left. This left us
particularly shorthanded, because our project would most likely require three programmers. The
options we discussed were to disband and join other teams, come up with a new idea, or de-
scope our project. We decided to de-scope the project as well as determine what tools we should
use to maximize our efficiency now that we were down a team member. The tools we picked
were tools that most of the team members were already familiar with so that we would not have
to spend time learning new tools.
Our Workflow
Another task we decided to tackle during that meeting was determining our workflow and
work processes. We did not know the specific details of each of the process tools, but we knew
we were going to use an Agile approach. Reflecting on it at the time of this writing, our
workflow was a mix between Kanban and Scrum. Our workflow was similar to Kanban, because
5

we used a Google Spreadsheet to visualize our workflow, and had event-driven releases; it was
also similar to Scrum in that we had one week sprints, a Sprint Review and Sprint Planning
meeting, and an implicit WIP limit per sprint. We also kept a backlog of features we would like
to have implemented. However, our Sprint Review sessions differed from the description of
Sprint Reviews from The Scrum Guide. We did not have clearly defined stakeholders, as we
were not doing this for customers, but for ourselves and the people who would play our game.
The players of our game cannot be considered stakeholders, because they are not invested in the
project. The closest thing to a stakeholder for this project would be the members of the team.
During our Sprint Review meetings, we played the game ourselves to determine the doneness
of each of the requirements.
Our workflow also differed from Kanban and Scrum. We did not explicitly limit the WIP,
and did not measure lead time. We also did not have the prescribed Scrum roles (Product Owner
and Scrum Master), our meetings were not time-boxed, did not have a Daily Scrum or a Sprint
Retrospective, did not score the requirements/user stories, which also meant we could not
measure velocity, and we did not commit to the Sprint Backlog, meaning not all items on the
Sprint Backlog were released at the end of each Sprint.
We also established our biweekly meeting times. We would have a Sprint Review and
Sprint Planning session every Sunday, and a status meeting every Wednesday. The purpose of
the Wednesday meeting was to determine if de-scoping or any adjustments needed to be made to
the schedule in case of unforeseen circumstances. To cancel or move a meeting date, a team
member must discuss it with the team during one of these meetings or send out an email at least
a day in advanced with a reason (and, if rescheduling, an alternative meeting time). The team
would then vote on the cancellation or proposed meeting time. If two or more team members
6

could not make a meeting, the meeting was automatically rescheduled for the next day at the
same time.
Establishing Our First Requirements
At the time of our first Sprint Planning meeting, we had a clear goal of what the project
should be, but no clear requirements. Based on what was needed, we came up with a few
requirements. The requirements were broken down into tasks, and the tasks were divvied up
among the team. All tasks were kept track of in a Google Spreadsheet (to visualize our
workflow). This spreadsheet also doubled as a schedule reference. All meeting notes were kept
in a Google Doc. If there was anything a team member wanted to discuss, he or she could put it
in the agenda in the next meetings section. All future requirements or desired features were put
in a separate Google Doc. This document also served as our backlog.
During our first Sprint Planning, we were unsure of how much we were capable of
getting done. Rather than having too little to do, we decided it would be safer to create what we
called stretch goals (essentially backlog items we can work on if we completed our work ahead
of schedule). These stretch goals became an important part of our Sprint Planning, as we
would always come up with them if we were running low on work.
Additional Challenges the Team Faced
At the start of the project, there were some apparent challenges we would have to
overcome to make the project a success. The most obvious of which was the lack of some vital
resources. Since we decided we would make a multiplayer game, we needed controllers to play
7

the game, as there is not enough room on one keyboard for four players, and most keyboards did
not have N-key rollover (meaning they cannot press more than three keys at the same time).
We also did not have the Pro version of Unity (the game engine we would be using). This
was vital, because Unity Pro came with built-in version control, which was easy to use. A couple
of members on the team were not familiar with any type of version control software, and walking
them through Git would have been too time-consuming.
New Additions to the Team: The Sound Team
Around the fourth week of development, we were offered the opportunity to be matched
with a music/sound team from Berklee College of Music. Since we needed audio for the game,
and none of us were experienced with creating audio, we decided to jump on the opportunity. We
invited the sound team to our next status meeting, and met in person. We got the formalities over
with, and got right down to business. We told them about our work process, and asked what
resources they had available to them, discussed what we needed from them, and what they
needed from us to make it happen. We also decided on a meeting schedule during this meeting,
and determined the Wednesdays would work best. We would extend the length of our status
meeting on Wednesdays to accommodate them. We also decided it would be most convenient to
meet virtually over Skype, rather than in person. This was a mistake and led to some headaches
later.
Advantages of Working in a Virtual Team
1. Convenient, met over Skype and did not have to travel
8

Disadvantages of Working in a Virtual Team
1. Communication response times were slower, because we were not sitting in the same
room
2. The virtual meetings were a big disadvantage
a. We missed verbal cues
b. It was also difficult to show visuals, because the free version of Skype does not
have video or screen sharing for conference calls
3. Did not know how much work was being done on their part, because we could not see
them working (also a bit of a trust issue here, because we were unfamiliar with them)
Even More Challenges the Team Faced
With the addition of the sound team, our group faced even more challenges as we were
inexperienced with late additions to teams and major scheduling conflicts.
The team did not start on the project together. Incorporating the sound team into our
workflow was difficult and it was equally difficult for them to incorporate themselves into our
workflow. The teams also were unfamiliar with one another. The original members of the team
were not familiar with working with audio people, and did not know what to expect or how to
incorporate them into the process. The audio team was not familiar with working with coders and
artists, and was not sure how to fit into the work cycle.
There were also some additional resource issues. The build of our game was for Windows
machines as that was the OS most of the original group had, but the sound team only had Macs.
This meant they could not play the game, and get a feel for what direction we were taking the
project. If we were able to create a Mac build, the controller button mappings for the Mac would
9

be different, meaning additional work for the developers. Even if we pushed a Mac build, the
sound team did not have controllers.
There were also a lot of scheduling conflicts. Berklees class schedule was different from
Northeasterns, luckily did not have to readjust the Wednesday meetings much. Berklee also had
a different Spring break time from Northeasterns. This meant there were two weeks where we
were not in touch with one other; during Northeasterns Spring break, and Berklees Spring
break.
Things That Worked Well
Although our team faced all these challenges, we had quite a few things that we did that
worked well.
We started early, which allowed us time to think about our ideas and plan accordingly.
The loss of our lead programmer happened at the beginning of the project. This allowed us to
readjust right from the beginning, rather than needing to readjust when work was already in
progress. We bounced back quickly from this unforeseen circumstance, and was able to push our
first prototype two weeks afterwards.
In general, our workflow worked well for us. It was highly flexible, which allowed us to
change the schedule as needed to accommodate the team members other classes, conflicting
schedules, and additional tasks such as refactoring of code and bug fixing. We did not have a
Daily Scrum, which saved time, because we would not have completed much work between days
due to other responsibilities. Releasing (play testing sessions) whenever we felt we had enough
changes to the game allowed us to gather more valuable feedback from classmates who played
the game; there would have been less significant changes had we released at the end of every
10

sprint. Always holding Sprint Review and Sprint Planning sessions after play testing allowed us
to incorporate user feedback into the project
We mitigated the issue with not having enough controllers by giving each developer a
single controller (provided by another member of the team who had two). We also brought the
controllers to meetings so we could work and test after meetings were over.
We avoided the issue with version control, by using Unity Pros built-in version control,
which was highly intuitive (but not as powerful as Git), and Google Docs, which the team was
already familiar with
We had a dedicated Producer (essentially our Project Manager), who handled most of the
documentation and paperwork the professor requested. This allowed the development team to
focus solely on coding. All documentation was visible to the entire team on Google Drive.
We determined around the third or fourth sprint that the game should be feature complete
by the first week of April, which gave us two weeks worth of slack. This slack turned out to be
much needed, as we worked down to the wire to get the project done on time
Whenever someone needed help or was overburdened with work, they would ask for help
or delegate the task to someone who had more time
Things That Did Not Work Well
Despite having done so many things well, there were a few key managerial things that
affected the team and the quality of the game.
Although our workflow worked out well for us for the most part, it could have used some
improvement. We should not have had the Sprint Review and Sprint Planning meeting on the
same day. This left no time for a break for the team to recharge. The constant stream of work led
11

to the team being burnt out around the fifth or sixth sprint. The burnout was due to a combination
of effort creep and being overworked. The schedule/sprint backlog spreadsheet shows evidence
of this. An increasing number of tasks were being pushed to the next sprint more frequently. (See
Appendix 1)
Some of the tasks were too large, and could have been broken down into smaller tasks.
The size of these tasks also contributed to the need for tasks to be pushed to the next sprint
The addition of the audio team was not handled well. We did not accommodate the audio
teams lack of resources. We also could have done a better job familiarizing them with our
workflow. We basically told them how we work, instead of showing them and giving them
hands-on experience. We also decided to meet virtually, which led to a slew of communication
problems, such as nonverbal cues going unnoticed, response times, communication overhead,
etc.
How We Should Adapt Next Time
We needed to improve on our workflow. The Sprint Review and Sprint Planning
meetings should not occur on the same day. There should be some time (maybe a day or two),
between them to give the team time to relax and recharge. During the fifth or sixth sprint, when
the schedule was slipping a bit, we should have discussed taking a few days off to rest.
As the lead programmer, I should have broken down the larger tasks to make them more
manageable. By failing to do so, I was constantly worried about getting the large tasks done,
which led to increased stress and eventual burnout. Alternatively, I could score each task, and
use a velocity measurement to gauge if I should break down the task further.
A lot of our problems with the virtual audio team could have been solved by meeting in
person instead of virtually. We would have been able to see nonverbal cues, gotten quicker
12

response times, get a feel for how each person communicates, etc. Meeting in person also would
have mitigated their lack of resources, as we had controllers and Windows machines. The audio
team would have been able to play the game and get a better feel for how they should have
designed the audio. Playing the game together would have fostered some camaraderie between
team members. Additionally, being and working in the same room would have given us very
valuable experience in working with an audio team. The experience would have also helped
them accustom themselves to our workflow.
Conclusion
The Game Capstone course gave us valuable experience working with cross-disciplinary
teams as well as managing ourselves within this environment. The project allowed me to gain
experience as a programmer and look into effective management practices. From these
experiences, I have learned that teams should work in environments that are effective for them,
and allow them to produce their best work. There should be some time to rest between sprints to
keep team members from burning out. Slack time is also very important, as unforeseen
circumstances or work is a guarantee on any project. Lastly, teams should meet in person if at all
possible. The co-location really helps in getting team members familiarize themselves with each
others work as well as build a relationship.
Appendix 1: Project Schedule