Agile methods and project management: the design of a project-oriented undergraduate game programming course

Earlier, I wrote about software architectural concerns for a course I am teaching in the Fall. In this 15-week course, I will be directing a team in the production of a history education computer game intended for Indiana's fourth graders. Specifically, the game explores Morgan's Raid of Southeastern Indiana. The game has already been designed, and I'm in the midst of writing the technical specification now. This tech spec will be used by the students involved in the game's production in Fall.

I am approaching this project with a modicum of trepidation. I have taught game programming courses in the past, managing teams of (if my memory is correct) five, four, and nine students. I have 30 students enrolled in Fall, an order of magnitude beyond the size of any team I have managed before. Beyond the sheer number of students, the distribution is not ideal: there will be ~30 Computer Science majors in the formal class and one Art major producing graphics. The artist is supported as an Honors Fellow and so can work up to 10 hours per week. Rather than dwell on what I would like to have, I need to focus on what to do with hand I have been dealt.

I have engaged in many conversations about this course, and I have received some wonderful ideas from both friends and friendly strangers. I am writing this post in order to foster further discussion with any interested parties and stakeholders, but before I go into the advice I have received and am considering, it is worth listing the invariants:

• There will be 30 undergraduate CS majors and minors of mixed experience level. They will have taken at least the standard foundations courses for my department: CS1 and CS2 in Java, Discrete Math, Calculus, and Data Structures & Algorithms, also in Java. Most will have taken some upper-level courses, but very few (maybe only one) will have taken software engineering. By my guess, about one-third of the students will have been involved with a semester-long software development project in the past, mostly from either software engineering courses or my HCI course.
• The class is scheduled for one-hour meetings at 2PM three times a week: Monday, Wednesday, Friday.
• The class is scheduled to meet in a conventional classroom. Thirty people in one of those rooms is very tight, making group discussion awkward though not impossible. We do not have any single lab where the class could meet regularly.
• I have to assign grades to the students.
• I cannot "fire" a student who satisfies the prerequisites and is enrolled, though students may drop the class without notifying me, until about halfway through the semester.
• We do not have a dedicated persistent space, although there are CS major labs that can comfortably sit 10-15 students at a time.
• I do not have tenure.

In addition to the invariants, there are some possibilities:

• We may be able to occasionally use the Schwartz Digital Complex learning pods room, which has six long tables for meeting and the capability to share screens across tables.
• I may be able to recruit some additional artists and musicians through colleagues' courses in other departments, or potentially on-the-side work by students who want to enhance their portfolios.
• There is a lab being renovated this Summer for use by students doing research-oriented coursework, primarily undergraduates involved in independent studies. We may be able to co-opt some of this space, but we would not have exclusive use of it (e.g. there are lots of whiteboards in the labs, but we cannot assume that what we write there will stay there for long).

I have not yet finished the technical specification, but right now, these are the specific technologies that I would like to incorporate:

• Game implementation in Java (close to invariant since it's my and the students' primary language)
• Continuous integration with CruiseControl
• Distributed version control with Mercurial
• Unit and integration testing with JUnit
• Distributed real-time communication with Google Wave. (This dovetails with my other major research endeavor.)

Without further ado, here are some of the project management ideas that have come up in my discussions. More accurately, these are the distillations of numerous discussions as well as readings and previous teaching experience.

The students are working for me.

On the first day of class, I intend to inform the students that they are working for me, and they are obligated to work a minimum of 10 hours per week on this class. Experience has shown that students often balk at this, though I mention it in all my classes. The math is simple: 12 credit-hours is a full-time student; 40 hours per week is a full-time job; this is a 3 credit-hour class. What they get in exchange for their effort, of course, is involvement in a very cool software development project that will be distributed throughout Indiana and beyond.

A colleague in Art runs a true studio-based learning environment. He was concerned that, although his students had developed significant technical skill, they had not yet understood deadlines and time management across projects. His solution: pink slips. Early in the semester, in order to establish the tenor of the class, if a student did not meet expectations or deadline, he would literally give them a pink slip and tell them that they lost their job and will be replaced by someone who respects the team. Of course, this was really a teaching moment---he could not actually fire students any more than I can. However, he said that students understood the message and, from then on, worked more explicitly at managing their time.

Along these lines, I am still considering the educational implications of the quotation from Alistair Cockburn that I wrote about earlier:

Use an agile process with the smallest number of people possible to get the job done; let the rest of the people do anything they want just so long as they don’t interfere with the progress of the development team. (From Agile Software Development: The Cooperative Game, second edition. Emphasis in original.)

Several colleagues whose teaching I admire have recommended naming the group to remind the students that this is not a conventional class, but rather a collaborative production effort. To this end, I would like to have a catchy name for our studio along with a professional-quality logo. It would be nice to have student input on this name, but it's not worth the time it would take to hold a class discussion. I see two possibilities:

1. Come up with a name and a logo this Summer and introduce students to it on the first class meeting. This will go along with the mental model of the students' being hired into the studio.
2. During the first week of class, push all of this discussion into Google Wave, including gadgets for voting. This will get students used to using Wave for collaboration, including the use of extensions.

Students, teams, and roles

Students will work in teams, because that's how software is built. The bad news is that approximately half of the students will have no team work experience. The good news is that most of those who have worked in teams did so in my HCI class, and so they had a trial by fire.

Ship It provides very straightforward advice regarding a critical team component: have a tech lead, someone who has one foot in management and one foot in technical implementations. As for who is the tech lead, I plan to have students apply for the position. I have not met with anyone who has tried this approach in an undergraduate class, but the concept has met with approval of respected colleagues who teach project-oriented courses. I will need to clearly articulate what a tech lead's responsibilities will be, of course, so that students know what they are getting in to. Also, since I cannot pay them any more, I need to make it clear what the benefit is, both in terms of investment (e.g. resume-building) and short-term gains (e.g. grading policy). For example, one of the tasks of a tech lead would be to provide his/her own team members with periodic formal evaluations: these should be incorporated into the grade of both the evaluator and the evaluated.

I am currently torn between social or functional team formation. (These are terms I am making up; let me know if there is a more standard expression for this, PMs out there.) A socially-formed team would be formed by students who know each other or believe they can get along. This is appealing since efficiency and effectiveness of communication seem to be the main bottlenecks in software development. Socially-formed teams could decide amongst themselves what kind of tasks they would like to tackle. Functionally-formed teams would be formed of students who share a common interest, and that interest would determine what tasks they take. For example, students interested in the game UI could work together on the "UI Team", and there is now a more obvious development of team expertise in one area of the production. One of the complication of functionally-formed teams is that it presupposes that I know the relative efforts required for various game features, which I don't. All the advice I have found is industrial and so focuses on the relative numbers of people needed to get the job done; none deal with the university oddity of having to deal with whoever signs up for the course.

A colleague in architecture suggested that there are two clear ways to promote progress with student teams: competition and collaboration. In a purely collaborative model, each team has a part of the solution, and their desire to create and to be good citizens leads to success. In a competitive model, teams work on the same parts of a solution, and the best among them is chosen for the deliverable. With 30 developers, it should be possible to adopt a competitive model, but I worry that those students whose solutions are not incorporated into the milestones will lose heart. On the other hand, if a team is given a module that is required for the milestone, and that team fails to contribute anything useful, then the collaborative spirit of the whole team is brought down. So I am left with the question, how much redundancy is appropriate?

Team size is another issue on which I am uncertain. I need to have clear communication with all of the tech leads, and so there cannot be too many of them. For example, if every team had three members including one tech lead, then I would still have ten tech leads to meet with and ten teams bidding for tasks. Of course, teams can easily get too large as well. There is an agile solution here, which is to allow for team reformation and role swaps during the semester, but I would like to have a starting condition that is representative of good practice.

Agile and Scrum.

There are too many unknowns not to be agile. I previously wrote about Alistair Cockburn's statement that, given a team of all novices, agile is practically the only way to secure success.

Last time I taught the class, I managed the team of nine students using Scrum, following the advice from The Scrum Primer. We managed our product backlogs and sprint backlogs using an OpenOffice spreadsheet, and we started each class meeting with a "daily" (twice weekly) stand-up. This worked well with nine students in a twice-weekly, 75-minute metings, but it will not scale to 30 students in thrice-weekly, 50-minute meetings. Fortunately, Google Docs is here to save the day. Its seamless sharing of documents gets us as close to a public, persistent information radiator as we can get. We used Google Docs in my HCI class last semester to share MSF-style risk matrices within teams and with the instructor and teaching assistant, and it was a fantastic experience.

One of the professional developers I met at Google I/O referred to the "bidding" process of Scrum, with which I am not familiar. The way we handled tasks in my previous offering of the class was informal: whoever spoke up first got it, unless someone else challenged it. If I understood this developer correctly, though, they used a model where individuals or teams would bid on the number of hours it would take them to complete, and whoever gave the best estimate got the task. This is an interesting idea, but it assumes that the bidders have reasonable estimates. Conversely, one of the best results of the last game programming class was that students got better at estimating: they were quite poor at the beginning, and most had never had to formally estimate effort before. This learning was evidenced by the product burndown charts, which started very erratic, but did actually approach linearity towards the end of the semester.

One of the most overt practices in many agile methodologies --- and Scrum in particular --- is the daily stand-up meeting. Unfortuantely, it is impossible to enforce daily stand-ups among student teams, especially with class scheduled MWF. My hope is that teams will conduct informal stand-ups via Wave or other communication technology on Tuesdays and Thursdays, and that proper face-to-face stand-ups can be held within each team during regularly scheduled meetings. This is another area where Google Docs comes to the rescue: it's straightforward to put sprint burndown charts into spreadsheets and have students update their estimates each day. Team managers can keep track of whether their team is updating their estimates, and as an instructor, I can easily scan a column and see if any team has a pattern of failing to update their estimates and take action. Failure to update an estimate also has very little impact on the overall project management process, since an empty cell can be assumed to have no change since the previous estimate.

During face-to-face meetings, individuals will be responsible for giving their stand-up reports to their tech-lead-cum-Scrum-Master, and these students will give their stand-up reports to me. This allows for a convenient filtering of obstacles: if a student tech lead has an inkling of how to remove an obstacle from the team's path, he or she is free to do so. If not, then it gets quickly reported to me, and I can design an appropriate intervention.

In this model, I share the role of Product Owner with my research collaborator and project co-director Ronald Morris, but I also serve as a sort of Scrum Master of Scrum Masters. I attended a workshop at CCSC:MW a few years ago in which Dean Sanders described using Scrum in a systems analysis and design class, and he would literally wear a different hat depending on whether he was acting as professor, Scrum Master, or Product Owner. (Incidentally, this was the first time I heard about Scrum and its use for agile teams in CS education. CS education conferences are a great place to share these ideas, so I'll see you all at CCSC:MW 2010. Why yes, I am publicity chair of that conference.)

Thanks to Google, I serendipitously came across Clinton Keith's new book, Agile Game Development with Scrum, and my copy is already in the mail. Hopefully it will contain some more tips that I can adapt into the university environment.


I am the lead architect.


Even though we're agile, there is no misconception that assumes the absence of documentation or architecture. I am still doing significant design work up front regarding the core system architecture. This comes from Tim Ryan's advice for game design documentation, which I have also written about before. A lengthy discussion of software architectural concerns can be found in my previous post.

I am also planning on providing some boilerplate code for the architecture, which will provide a concrete example of good programming practices, including documentation, modular design, and unit tests. As mentioned before, these concepts will be new to many students, and so providing this code will allow for bootstrapping for less-experienced students. For example, I am considering leaving out some simple functionality from the code that I provide specifically so that teams can explore the space where the various technologies meet and also achieve a "little win" to build their confidence. This follows more advice taken from Cockburn's Agile Software Development book: start with a task that you know you can complete, then build an end-to-end prototype (i.e. walking skeleton), then prioritize by story points.


 Class Meetings


A future post will explore pedagogic implications of these designs, but allow me to say for the time being that this learning experience is being designed according to principles of project-based learning, along the lines of studio-based learning and 

legitimate peripheral participation. To me, one of the most inspiring aspects of legitimate peripheral participation is that apprentices learned more from practice with masters than from any explicitly didactic methods. 

With this in mind, then, class meetings are simply team meetings, and what we have to learn is completely reified in what we have to do.


Even though I believe that this is the best approach for this learning experience, it makes me a little nervous due to the departmental and university culture. Although the administration has made laudable efforts to promote the "Immersive Learning" brand, many faculty members --- including my departmental colleagues --- have different philosophies of education. Studio-based methods within pure project-based learning environments may cause ripples in the year that a decision is made about my tenure!


Closing Remarks


I am grateful to all those people who shared course design ideas with me, and I am excited about integrating some brilliant ideas about both software development and the science of learning into this experience. This novella of a post has taken me hours to write, but it has allowed me to crystallize many of the ideas that have been floating around my mind, and to identify the areas in which I still am uncertain.

I welcome feedback on all aspects of the course design. Loyal readers will be treated to a few more posts during Summer planning, and then regular reflections during the Fall semester.