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 team s 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 semester s 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 descope 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 meeting s 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. Berklee s class schedule was different from Northeastern s, luckily did not have to readjust the Wednesday meetings much. Berklee also had a different Spring break time from Northeastern s. This meant there were two weeks where we were not in touch with one other; during Northeastern s Spring break, and Berklee s 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 Pro s 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 team s 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 other s work as well as build a relationship. Appendix 1: Project Schedule