GDG Muncie Slides on Serious Game Development with Java

On Friday, I gave a talk to the Muncie Google Developers' Group on the topic of serious game development with Java. It is a refinement of the talk I gave at the IndyJUG in Summer 2013. The notes from that presentation are still appropriate, and I promised I would post the slides as well, so here they are (PDF).

In retrospect, I probably could have split the presentation half, focusing on some interesting technical aspects of Morgan's Raid or Equations Squared and saving the other for another presentation. It's relatively easy to design a presentation for a group with similar experience and ability, such as an undergraduate course, compared to the variety at a public meeting such as a GDG or JUG. Something to consider, anyway. After having been giving public talks on game design recently, it was nice to give a talk on the more technical side.

Thanks to Chris, the Muncie GDG organizer, for the invitation to speak, as well as the nifty new mug. Here it is in its inaugural use, Monday morning before my 8AM class, a light roast of Papua New Guinea beans from Compulsion Coffee.

Add caption

Applying Burgun's Lens of Game Design

I recently read Keith Burgun's Game Design Theory, an intriguing manifesto on game design and philosophy. The author argues that reasoned discourse about games requires a shared vocabulary, and to this end, he offers the following hierarchy of interactive systems.

Burgun's hierarchy of interactive systems
(Taken from What Makes a Game?)

Burgun's defines a Game as "a system of rules in which agents compete by making ambiguous decisions." More specifically, these decisions have to be endogenously meaningful in terms of the game mechanics. Whether or not one agrees with his definition is less important, in my opinion, than the fact that a vocabulary helps us move forward in the science of design.¹ 


The hierarchy of interactive systems permits Burgun to explain what he's not talking about: because he wants to address game design, he can cut out problems of interactive system design, puzzle design, and contest design. Many of his game design recommendations echo what others have to say. However, it's Burgun's zealotry that makes his work so valuable: he makes fewer and stronger recommendations. In the introduction, he discusses how he sees his work with relation to other books on game design:

For those who might defend these books by saying that they're only giving readers wiggle room or that they're allowing readers to come to their own conclusions about what games are: readers do not explicitly need to be given permission to do this. Thinking persons will come to their own conclusions, regardless of whether they read something wishy-washy, or something pointed... (Introduction, page xx)

This sets the tone for the rest of his book. He is unapologetic about his philosophy of game design and leaves it to the reader to decide whether they agree or not. In fact, I don't think anyone who is serious about game design could read the book without being either uplifted or offended.

In an attempt to better understand Burgun's philosophy, I decided to apply his lens to some of my work and my students' projects. The following analyses assume familiarity with his philosophy, and while this is best presented in the book, there is an overview in the freely-available Gamasutra article, What Makes a Game?


Morgan's Raid

According to Burgun's lens, Morgan's Raid is a Puzzle² because there is no randomness: a play experience can always be replicated by repeating a series of decisions. The goal of the puzzle is to maximize score, which is themed in the game as Morgan's reputation. The impact of a player's raiding decisions on reputation are not immediately clear: a player must choose all of his orders prior to seeing their combined effect, although Basil Duke does provide thematic hints.

Basil Duke informs the player that he will help explain the puzzle.

There must be a series of decisions that maximizes reputation, but no one on the development team knows what it is. From our observations, groups of players will gladly make it a contest to see who gets the highest score, although their interest in the game wanes well before anyone finds the optimal path.

It is interesting to note that the original Spring Team design for Morgan's Raid involved more interesting behavior of the Union troops who were chasing Morgan, such that this would have made the project a Game. The original plan was for the Union's movement to be like Morgan's, making heuristic decisions in each town in an attempt to capture the player. However, working within our time constraints, we simplified the Union behavior to make them a fixed integer distance from Morgan. This distance is modified by player's decisions but in a fixed and predictable way.


Museum Assistant: Design an Exhibit

Museum Assistant is also a puzzle, albeit one with multiple solutions. Players get themed feedback based on the solution chosen; for example, creating an exhibit with African scientific artifacts from three different periods yields the generated exhibit title, "African Science through the Ages." The themes provide reason for players to try alternate paths, but from a mechanics point of view, one solution is as good as any other.

As with Morgan's Raid, Museum Assistant underwent a design change that resulted in its moving from Game to Puzzle on Burgun's hierarchy. Details of this design are described in my MeaningfulPlay paper, but to summarize, there were systems of input and output randomness that made it so the same series of game actions could produce different results. However, in the major redesign we agreed that we needed one good play experience, and that balancing the ambitious original design was outside of our scope. In terms of Burgun's hierarchy, the team decided to make a good Puzzle rather than a bad Game.


Equations Squared

While the previous two examples are student work, Equations Squared is my own, and it's certainly a Game. The player makes strategic decisions about placement of digits and operations, in terms of which to use and where to place them. Not all sequences are legal equations, and the scoring system rewards more complex equations. There is input randomness: the sequence of digits and operations you receive is different each time you play the game, so you very likely will never play the same game twice.

Auralboros

Auralboros is an experimental make-your-own-rhythm-game toy. You can make the experience as simple, as challenging, or as ridiculous as you want. To this end, Auralboros is simply an Interactive System.

Auralboros encourages players to make their own Contests out of matching keystrokes in rhythm. The system rewards such behavior with visual feedback. There's no ambiguous decisions: you either make and match rhythms or you don't. In fact, a successful strategy to seeing all the visual bells-and-whistles is to spam a single key—a useful debugging technique discovered by co-developer Ryan Thompson. However, this strategy is not much fun, as you end up just making a bad Contest.


EEClone

I still occasionally install and play Every Extend (though it seems the original download site is now gone), usually after explaining to students what an amazing experience it is. EEClone is my academic knockoff, designed to explore and teach how design patterns occur in game engine software.

Like its inspiration and namesake, EEClone is a Game. The timing and orientation of incoming obstacles is not known, and the player has to make meaningful and ambiguous decisions about maneuvering and the timing of explosions in order to succeed. Of all these analyses, this one is the simplest, but it also shows how things that are obviously Games fit nicely into the hierarchy.


Conclusions

Most of my effort the past few years has been on serious games. As I use the term, serious games are those that are designed to have a particular real-world impact on the player. For example, Museum Assistant is designed to encourage players to think about collecting and curating. Applying Burgun's lens to my students' projects gives rise to an intriguing contradiction: serious games need not be "games" at all. However, Museum Assistant is no less successful in meeting its design constraints for its being classified a Puzzle. This is because the real constraint for serious games is serious, not game. It is difficult to say whether or not these projects would better meet their goals (however one defines "better") if they were Games, because this would fundamentally change them. For example, we know that Morgan's Raid could be a better Game if the maps were randomized, but this violates the goal of familiarizing the player with actual Indiana geography.³

The Morgan's Raid and Museum Assistant teams recognized that there were opportunities to make a better game—or from a strict reading of Burgun, to make Systems and Puzzles into Games. Both teams eliminated randomness in the face of time constraints, knowing that balancing games would be much more time-consuming than testing puzzles. This was shared knowledge among the team, although they didn't have Burgun's concise language to communicate the sentiment. In a similar vein, the Auralboros team was aware that we weren't really making a game at all. It is interesting to note that Equations Squared is a Game by Burgun's hierarchy, but it is not a serious game by my own definition. For the player, it is simply supposed to be fun. The serious aspect of it is in the assessment of player's behavior, an assessment conducted by someone outside the magic circle but facilitated by score, badges, and demerits.

Applying Burgun's lens to these projects has helped me to understand his philosophy. However, since much of his philosophy is prescriptive, there is not much extrinsic value in applying the lens to completed projects. That is, I do not think I gained any new insight into these projects, but then again, as an academic, I've already studied them inside and out. I do look forward to having Burgun's philosophy in my utility belt for future design projects, particularly as a lens for identifying and discussing decisions that could alter a project's position in the hierarchy. Next semester, I will be leading an experimental six-credit interdisciplinary game design and development studio, and you can be sure I'll try to keep up my reflective practice here on the blog.

---

¹ At MeaningfulPlay, I got into a bit of a debate with a gentleman over the definition of "fun." He argued that a friend's autobiographical game designed around the theme of depression and abuse, in which you decide whether or not to commit fantasized patricide, could not be fun. I said that if it was a game, and if I was using Koster's operational definition of fun as learning and mastery of a system, then it could be fun, though perhaps not in the informal "enjoyment" sense. My point was that if we defined these terms, we can be clear about our meaning and avoid the baggage. He didn't talk to me any more. I tell this story to demonstrate that I am surely in Burgun's design philosophy camp, and that there is a dangerous cultural divide in "game design" that prevents communication across traditions. See also Daniel Cook's excellent essay contrasting secular and mystical approaches to game design.

² As a typographical convention, I will capitalize the layers of Burgun's hierarchy so as to distinguish the layer "Puzzle" from the general use of the word.

³ We are currently conducting an empirical study on the effectiveness of Morgan's Raid, and I will report the results here when we have them.

The Components and Systems of Morgan's Raid

I've written before about the entity system architecture of Morgan's Raid. I am just now polishing a paper on the topic which I will present at the FDG conference in May. I contacted Adam Martin to get his feedback on the paper, and he was very helpful. He made a few suggestions that I simply did not have space to address in the eight-page conference paper, but since Blogger has no page limit, I would like to address one of them here: what are the actual components and systems of Morgan's Raid?

By way of simple introduction, an entity system architecture is a software architecture in which game object data is stored in simple objects called "components" and these are processed by "systems." Game objects then are simply unique identifiers that aggregate components. This approach favors delegation over inheritance. It proves useful in game development due to the highly experimental nature of such systems: the domain model itself is subject to dramatic change during practically every stage of development. For further discussion, check out the entity systems project wiki.

Numbers of components and systems during development

The figure above shows the growth of the number of systems and components during the development of Morgan's Raid. This figure appears in the paper with a brief interpretation. I provided the small initial set to help bootstrap the students, but most of the rest were written by them—the 25 developers who worked in Fall 2010 and eight who worked in the Spring 2011. I am very proud of the team, don't confuse my pride in their achievement with any claims of elegance and beauty. Indeed, there are quite a few smells in our implementation.

Without further ado, tearing into the source code of Morgan's Raid, we can see how the systems and components are related. (It appears that Blogger automatically scales large images down. You can grab a full-size PDF here.)

System-Component Dependencies

The systems are on the left and components on the right, with edges showing system-component dependencies. As evidenced by the diagram, there are a few components which are heavily used throughout the implementation. OnScreenBoundingBox, for example, is used by anything that involves bounding boxes. (This was originally called Position, but that caused serious confusion when dealing with world vs. screen coordinates. After refactoring, we ended up with OnScreenBoundingBox and GPSPosition, the latter because world coordinates were actual GPS coordinates.) There are a few systems that have no out-edges because they use no components at all. For example, FadingSystem handles the fading of the screen based on time of day, but it does not deal with a component explicitly: it is passed a long integer that represents the current time of day and performs its computation from that.

Several of the components have no in-edges. A handful of them are, sadly, rotten code that was never removed. In fact, some are added to game objects and never accessed by anything else. Others of these disconnected nodes are used directly by the non-system game code. The Morgan's Raid implementation reifies the state design pattern, and there are many places where critical game logic was done directly within these classes rather than delegating to explicitly named and tested systems. This is not ideal, and I ascribe it to the novice level of many of the developers. Ask anyone on the team what they think about the 1700-line behemoth InGameState and they will cringe and tell you it should have been done better, but at the time, they did not know how to actually make it better.

In the diagram above, I have hidden the inter-system and inter-component dependencies for one very good reason. When they are shown, the diagram becomes a bit of a mess. Check it out (or full-size PDF here).

System-System, System-Component, and Component-Component Dependencies in Morgan's Raid

Ignoring for the moment the fact that you cannot discern the system-component dependencies, this diagram does show that the number of system-system and component-component dependencies is relatively low. However, if I were to throw InGameState into the mix, it would have its fingers in practically everything.

The diagrams were generated with dot, and you can download the graph file here. (Note that Google Docs thinks this is some kind of Microsoft file due to naive handling of file extensions. Just download the original and open in your favorite plain-text editor.) I created that file manually by inspecting the Morgan's Raid source code, and so it may contain minor errors.

For your reading convenience, here's a simple tabular view of the systems and components as well.

Systems

Components

BackgroundTileSystem CityNameSystem DestinationSystem FadingSystem GPSToScreenSystem HoverableSystem ImageRenderingSystem IntInterpolationSystem MinimumSleepTimeSystem MorganLocationSystem NightRenderingSystem OnClickMoveHereSystem OnScreenBoundingBoxSystem RaidSoundSystem RailwaySystem ReputationSystem RevealingTextSystem SpeedSystem StepwisePositionInterpolationSystem SunSystem TimePassingSystem TimeTriggeredSystem TownArrivalSystem TownArrowSystem TownUnderSiegeSystem

AnimationRenderable ArrivesAtTownIndex BackgroundTile BeenRaided CentersOnGPS CityData CityImages CityName CityPopulation CityTargets CommandPoint Destination DoesCityHaveMilitia DoesCityLoseGame DoesCityWinGame GPSPosition GPSPositionList HasMorganGPS Hoverable ImageRenderable ImageRenderLayer InGameTime IntInterpolated MinimumSleepTimeOverride Morgan MorganLocation MovesOnClick OnClickMoveHere OnScreenBoundingBox OnScreenBoundingBoxList PositionInterpolated Raidable Raider Railway Reputation ReputationValue RevealingText Road RoadsToCity RouteTaken Speed Sun Terrain TimeToRaid TimeTriggeredEvent TownAdjacency TownArrow TownUnderSeige

CS Ed Week: Reflections on a busy week

Once again, we've reached the end of CSEdWeek, and I'm pushing to get this post in before it's over.

I attended two blogworthy public events this week. On Monday, I went to the Indiana Historical Society's Annual Founders Day Dinner and Awards celebration, along with my collaborator Ronald Morris and our Dean, Michael Maggiotto. The College of Sciences and Humanities at Ball State University was awarded the Outstanding Project of the Year award for Morgan's Raid.

Among the other recognized individuals and organizations were eight Centennial Businesses, Indiana companies celebrating 100 years of operation. Not surprisingly, none of these were software development companies. However, I'm willing to wager that all of them now rely upon software for their daily operations. In 2111, will they be looking back at 100-year-old software development shops?

Wednesday was the BSU Building Better Communities Project Showcase, where about twenty student teams showed how they worked with faculty mentors and community partners. Several of my students were there to demonstrate the Digital Archaeology Simulation project. A poster provided the background and rationale for the project, and the software is still under development by Emerging Technologies. A prototype was available, and while I didn't take the opportunity to run the latest build, several passers-by told me that they were quite impressed. Ball State University President Jo Ann Gora spent a few minutes with members of the team to talk to them about their work—a great opportunity for the students to show some of their best work (even if the photo is rather poor).

This week was also the final project presentations in CS222: Advanced Programming. Each team of four had to pitch a project and complete it in six weeks, with two three-week milestones. Several of the teams impressed me with their hard work and dedication, investing significant amounts of their own free time in order to create the most impressive systems they could.

Rather than make any grand conclusions, I think the best way to close this post is to say that I have a great job. My students rise to the challenges I set before them. They appreciate learning how to learn, and they respect the fact that I respect them. We all get a bit stressed this time of year, but it feels good at the end of a busy week to reflect on all the great learning experiences I have had with my students this year. Thanks to my students for sticking with me, for trusting me even when my methods are unconventional.

Happy CS Ed Week.

Morgan's Raid on CD

We recently received a request to make Morgan's Raid available to a school that has blocked Internet connections from its lab machines. Morgan's Raid was built for distribution via Java Web Start (JWS), which simplifies the process of dealing with native libraries. However, as the name implies, the technology was designed for computers with Web connections. Distributing as an executable jar is not possible because they do not adequately handle native libraries.

The JNLP file contains all of the configuration information for JWS. This includes codebase, through which JWS determines where to find referenced resources. The Morgan's Raid codebase points to the server that hosts the jar files, for example. Turns out that if you leave out the codebase, it will default to the same path as the JNLP file itself.

My next step, then, was to revise the Morgan's Raid JNLP file for local files. I created a CD containing all the requisite jar files and the revised JNLP file. Running the JNLP file off of the CD almost solves the problem. The game runs, and it creates a desktop and start menu shortcut in the process. However, it also records the fact that the jar files came from the optical drive. As a result, the game will then only run with the CD in the drive, even though all the jars have been copied to Java's cache: JWS still tries to check the codebase to see if there's any changes to the files or configuration.

The problem is easily solved by having the user copy the CD contents to any folder on their hard drives and running the JNLP from there. Now it's this path that is recorded by JWS, so using the desktop shortcut or start menu shortcut will happily run the application locally. This gets the desired result that I can hand someone a CD, and they can put it on as many machines as desired, without my having to fiddle with installation software beyond JWS. (I guess that changing the location of those files would break the installation, in the same way that removing the CD did before, but I did not verify this.)

With my CD experiments successfully concluded, and after a little help from my department's friendly system administrators, the result looks like this:

I found it deeply satisfying to hold this disc. Physical media doesn't change the existential state of the software system, but there's something about holding this disc in my hands that made the software more real.

As I was printing the CD, a sysadmin asked, "Does it have to be on CD?" Her reason for asking was that she had blank white DVDs, on which the printed label would be more crisp, but I thought she meant, "Can't it be on something other than a disc, like a thumb drive?" I laughed aloud when I realized that I had never considered anything but an optical disc for this project, because, you know, software comes on discs!

A new team's first Daily Scrum

We spent the first several weeks in my game programming class covering the basics and exploring two platforms for game development, Slick and Unity. On Monday, the eleven students decided that for their semester project, they would like to work on one big team to try porting Morgan's Raid to Unity. I decided to mentor the team using Scrum, since that has worked so well for me in the past. For Wednesday, I put together a product backlog and the team had its first spring planning meeting. While I had recommended that the students read The Scrum Primer, I got the distinct impression that the vast majority had not done so; in their defense, I had emailed the link Tuesday night.

The planning meeting went well, although fifty minutes was awfully tight to introduce the fundamentals of Scrum and to do the planning. I used my Scrum diagram as a reference to talk through the process. We were missing three of the eleven team members, but we were still able to get a reasonable number of stories committed for the first Sprint.

Today was the team's first "daily scrum." At 8am sharp, everyone was present. I told them to get into a circle and report what they had done since last time, what they had planned for next time, and what were the impediments. They got up and moved to the open area in the front of the classroom, while I stood behind the teaching station.

Here's where the team really surprised me. In using Scrum with students many times in the past, I have found that they find it challenging to report to each other, that they prefer to report to me. I wrote about how my Summer team was able to leverage the physical space to have productive Daily Scrums, but that team was half comprised of people experienced with Scrum, so their team-facing attitude was to be expected. This team of eleven had one student with Scrum experience (Tom), and the rest had none. They formed the circle and showed a few signs of anxiety, but Tom started right in with his daily status. He passed it on to the teammate by his side, and the whole stand-up meeting went as smoothly as one could hope.

There are four differences between this team and those from my past experiences, and I suspect that each is a contributor to this team's success. First and foremost, I learned a lot about managing a Scrum team through my experiences last academic year, and so I was more careful to separate myself from the stand-up meeting. Second, there was the issue of physical obstacles between me and the team: as with the Summer team, the furniture provided a convenient separation. Third, there was exactly one team member who had Scrum experience, and he showed no hesitation in starting the meeting and reporting progress to the team. Whether he meant to or not, his example provided the perfect template from which the other students intuited the expected social behavior. Fourth, all save one of these students have taken previous courses with me in which we repeatedly applied principles of agile development. We did not use Scrum in  particular, but we discussed the philosophy and the implications as well as learning the practice through a six-week project in two deliverables.

I wish I had more data to support that last point. I would love to be able to claim that the students' experience in CS222 is a contributing factor to their ability to work in teams in upper-level courses, since that's one of the explicit goals of CS222. Unfortunately, the assessment data is not that rich. I mentioned three other contributing factors, and there are undoubtedly more. Still, it's anecdotal evidence that some combination of my teaching and the curriculum are working in tandem to improve student learning experiences.

Guest Post at Play the Past

My guest post at Play the Past is now online. It provides a birds-eye view of the design and development of Morgan's Raid, which I have written about extensively here.

Morgan's Raid Postmortem

Morgan's Raid enjoyed its public release at the Conner Prairie Educator Event last Thursday. With that event, the project is essentially "done," modulo the inevitable maintenance. For the past few weeks I've been sketching out notes for a postmortem in the style of Game Developer magazine, and now I'd like to share these with you. In truth,  I vary a bit from their style, looking more at structural elements of the team than technological decisions, but this is natural given the dual nature of the project, which was designed to create something significant while also meeting learning objectives for the developers. (As I think about this, it would be interesting to write one in their style too, but that's a task for another day.)

What went well

Scrum

The application of Scrum was excellent, especially as we refined our process in the Spring. The students and I appreciated the public nature of the task board, and they healthily struggled with what it meant for a team (not an individual) to commit to a task. The impact of the burndown charts was evident in how students discussed their work and our progress, and the sprint renegotiation process was relatively smooth. The sprint reviews and retrospectives gave the team a chance to analyze and discuss the product and the processes, and their empowerment helped fuel their continued motivation.

Our modifications to Scrum were relatively minor. Because the team only met three times per week, we did not have daily stand-ups, but our "once-per-workday" stand-ups were sufficient. One aspect that we completely dropped was the product burndown chart. With our already low number of collaborative, collocated working hours, I decided against adopting formal planning poker sessions. In the Fall, I made up story points based on my experience as a developer and a teacher, and in the Spring, we skipped these entirely. I do not doubt that they would have been an academically interesting feature to keep, but aside from academic intrigue, I think I made the right call to slim Scrum down a bit.

Due to scheduling issues we could not control, our artist could not meet with the developers in the Fall. As a result, his work was rather undirected and his contributions relatively few. In the Spring, he was able to meet with the developers, creating a real cross-functional team. The results were amazing, and I need to be sure to promote cross-functional teams in future experiences. This is not directly related, but I'm sure that our separation of "designers" and "developers" in the Scourge of Orion project was a major contributor to its lack of productivity.

Playtesting

Our external playtesting experiences were fundamental to the success of the game, and I express again my gratitude to those teachers and schools who shared their time with us. I know that I learned a lot by seeing how the end users interacted with our various prototypes, but more importantly, I could see how it helped the developers build empathy for the end users.

It was especially useful to playtest with different demographics. "Indiana fourth grade students" encompasses a wide variety of skills and dispositions, and even in our relatively limited playtesting, we were able to witness this range. I suspect that this perspective not only helped the team to design the game but also to develop empathy for the challenges of the elementary school system.

Every child who played Morgan's Raid gave us some feedback, and often they had feature requests. Some were clearly outside of our scope, such as adding multiplayer support and leaderboards. Many others were based on the students' experiences with school and educational software. At some point later, I plan to write a more detailed piece on why there are no quizzes in Morgan's Raid, despite this suggestion being proffered by many playtesters. What was more salient to this post is that some of the team members jumped on these recommendations, an unspoken assumption being that we should provide what the intended end users wanted. There's a deeper anthropological lesson here that I tried to explain to the team, that while the users are always right, they also aren't experts. This brings us back to the design issue mentioned earlier, that experience design is difficult, and it's important that someone have the power to veto.

Development methodology: Entity system architecture and Mercurial

I have written before about the entity system architecture, and I list it here as one of the great successes of the project. Adopting this architecture allowed us to separate tasks rather seamlessly, certainly better than I had experienced before in working with teams of undergraduates.

The fact that this was a team of amateurs is significant. The ideals of proper object-orientation can and should lead to modular, robust, scalable software systems. However, because the students lack experience, perspective, and technical understanding, it is insufficient to give them a software design task and expect production-quality results. Even with the entity system architecture, there are parts of the code that are ugly to behold, unnecessarily coupled across disparate systems. That said, the fundamental idea of the architecture—decoupling behaviors into components, which are acted upon by systems, and combining components into entities—was simple enough that it could be explained with a few examples and then applied by the team.

Maybe I'm cheating by putting two in one here, since the version control system is orthogonal to the software architecture, but I'm going to mention it here anyway. This was my first time using a distributed version control system, and Mercurial more than proved itself. The students were able to learn it quickly and became quite savvy with the workflow. It was a little distressing that even at the end of development, some team members were mad at Mercurial for making them merge, where I would have liked them to adopt the more enlightened perspective that merging is a necessary part of teamwork, and Mercurial made it infinitely easier than doing it by hand.

Spring Space

The use of a dedicated space in Spring was fantastic. This is not easy to come by in a university setting, and on behalf of the entire team and our stakeholders, I am grateful to my department for granting us the use of the room. Everything one would expect to improve was improved. While the Google Docs approach to managing the Scrum artifacts was reasonably effective when working with the 25-member team in Fall, it pales in comparison to the power of three giant whiteboards and piles of sticky notes in the Spring.

The incredibly impact of dedicated space has made me an evangelist for more responsible use of university resources. It got to the point where, on the Future of Education Task Force, people would just put "space" down for me in any list of things we need to change. Space is a deeply political issue on any college campus, but one important lesson I learned is that I should pay more attention to it during the planning stage of any future activity. If I can find any partner who is wiling to pony up space as part of a grant proposal, for example, I'll jump on it.

Team formation

It was great to see how the team gelled, especially the smaller group in the Spring. They really were a functional independent game development team in every way that matters. There was some work that I did to try to foster this sense of team, such as adopting agile methodologies, bringing goodies for Sprint Review and Retrospective meetings, and hosting board game sessions. These definitely helped, but I also could tell that the students were hungry to make something important, to do something that mattered beyond a credited learning experience. Even if we all had our own idiosyncratic views of what Morgan's Raid should be, we shared this vision of being able to work together to make something significant that none could do on his or her own.

The only distressing part about this success is that the team is now gone. Usually, at the end of fifteen weeks, I am ready to push my students out to face their next challenges. With this team, a part of me wishes I could keep them here so that we can continue to face challenges together. I build an emotional bond with these undergraduates. They were my teammates and coworkers, my partners in a difficult endeavor, my colleagues, and my friends, and I will miss them.

What didn't go well

Code reviews were not in our methodology

We did not have formal code reviews, and in retrospect, our code quality suffered because of it. It is easy at the time to ignore reviews in favor of "productivity," but I think this was a classic managerial blunder. I am not certain  what methodology we could have used in the Fall to promote this, but we certainly could have inserted some more formal code reviews in the Spring. This would have directly helped us meet some learning objectives while improving the code base, since as I and others have said before, software development is a learning process.

Because of the generally poor code quality from Fall, I made sure to introduce a formal verification step into the task approval process. When I had the time and energy, this meant that I would not just check that the task was working, but that the underlying implementation was reasonable; however, working under our significant time pressure, I often did not have the time and energy.

In truth, I do not have much experience with code reviews. Sure, I've graded countless assignments, but these have primarily been summative assessments, not formative assessments. This is not an excuse but rather an opportunity for me to include code reviews into a future experience, so that my students and I can learn together how best to use them in our environment.

No technical specification

I invested a significant amount of time in Summer 2010 working the results of the Spring design colloquium into a functional design specification. This took the form of a wiki on Google Sites, and it was shared with all the team members and product owners. This was a colossal effort, since the output from Spring was nowhere near the quality we expected, and so really I was redesigning the whole game from disparate prototypes—and even then, what I wrote up was not that good and ended up being significantly changed before shipping. This does not mean it was wasted effort: it was still a necessary step along the way. However, because this took all of my spare cycles in Summer 2010, I was out of time when it came to the technical specification. I wrote up a few notes about methodology (inspired by Cockburn's excellent book that I read the same Summer), but for the most part, the software architecture was only in my head.

I suspect that the lack of a technical specification was a major factor in the relatively low productivity of the Fall semester. I believe that the productivity of Spring would not have been possible without the learning of Fall, but at the same time, and as pointed out by a team member the other day, much of the Fall was undirected learning. That is, the students were learning, but they didn't always know where they were going with this. Being able to rely on, for example, a software architecture specification, could have helped them see how their little piece was actually going to make a big difference.

Undergraduates, by and large, do not have the perspective necessary to design large software systems. After all, having wide perspectives and the ability to integrate across disciplines is an outcome of higher education, not an input. I'm sure a technical specification would not have improved Fall's productivity by an order of magnitude, but it would have helped a little. Most importantly, it would have helped the students see, from early in the process, the value of documentation. About two-thirds through the Fall semester, we did a massive architectural overhaul, and to get this done, I turned to de facto standard UML. Once the students understood how this language was part of my bigger process, they could see the value in it and showed interest in learning it. I suspect this transformative experience could have been brought about earlier through more formal technical specification.

IP

Dealing with the university's intellectual property policies has been an exercise in frustration. I suspect that mine is like a lot of other institutions of higher education, where tight budgets are causing the administration to jump on the commercialization bandwagon, and yet the staff has little or no experience dealing with software innovations. As a point in case, I have yet to meet anyone at the university who seems to understand software licensing, and all of the forms and procedures are aligned with physical invention.

In the university's defense, I put off dealing with IP until we were 90% done with the project. I just didn't want to deal with it, because I knew it would be a quagmire. Sure enough, it was, and still is, since some of our issues are still not sorted out: I was told that I would receive official written documentation on some issues over a month ago that I has still not arrived. I suppose I should have started the internal processes earlier.

On the positive side, all of the programmers have agreed to license their code under an OSI-approved license, and so I hope to make a source release of the game and announce official licensing policy by the end of the month.

The takeaway on the IP front is that, in future projects, I should deal with it earlier on, ideally during the proposal process. This would lead to a traceable paper trail and explicit acknowledgement of the funding agency of the intended licensing strategy, and we would only have to go through the current headaches if things changed.

Undergraduate game designers

I hesitate to mention this here since several of my undergraduates may read this, but understand that I write this with respect and affection.

We put too much faith in undergraduate designers. Game design is hard, and I posit that legitimate educational game design is even harder. I think what we asked of our Spring design colloquium class may have been impossible for students at that level of experience. Not only were they lacking game design knowledge specifically, they had essentially no prior experience with design thinking at all.

I recently took the time to reflect on the game designs I have come up with during my lifetime. I've always been a hobbyist, and specifically, I remember writing up rules for a tabletop RPG that got some playtesting when I was an undergraduate, and I sketched out at least one CCG rulebook that was circulated among my friends in grad school. When I look back at these, I made classic amateur mistakes, prioritizing the wrong elements and trying to do big design up front rather than incremental and iterative design. That is, I knew nothing formally of design thinking. As I reflect on what my students designed, in the design colloquium and during the evolutionary design of the development process, I see the same kinds of amateur mistakes.

For those who were on the team for more than one semester, I'm sure that they saw how I made changes to cope with these observations. The design colloquium was very open-ended, but in the Fall and Spring, I positioned myself as the design authority. While anyone could pitch any idea to me—and indeed the great design successes of the game are primarily student-generated—I was the gatekeeper, and there were many directions that I forced to be shut down. As benevolent dictator, I needed to ensure that energy was being spent fruitfully, even if it was perceived as less glamorous by the team.

Trying again to look forward, I think this will have to be the perspective I take in future endeavors. We were probably not critical enough in the Spring, and there wasn't enough time in a three-credit course for the students to develop healthy levels of design self-criticism.

Attention management

In the Spring, we had an excellent space in RB368, and I am sure that the success of the project rested in having access to the space. That being said, I'm not sure that I managed it correctly. As I have read more about agile software development spaces, I realize that we did not have a good management system in place for dealing with distraction. Our shared workspace was regularly interrupted by both related and unrelated events. I know there were several times where I was in the zone and then got broken out of it by well-intended interruptions.

For many students (at least it is said), working in a high-distraction environment is their modus operandi. The sad result is that they have no idea how much productivity they are losing, since they are not intentionally managing their attention. This would have been a good learning opportunity for them to see what being productive really felt like. Next time around, such as next Spring's VBC seminar, I will be more explicit about working conditions. I am confident that this can be done without negatively impacting the social bonds of the team, and in fact, I suspect it will lead to an increase in mutual respect.

Morgan's Raid Extravaganza

I uploaded the beta version of Morgan's Raid the other day and did some work to beautify the Web site. Play the beta or find out more at https://sites.google.com/site/morgansraidgame/

The latest Emerging Media Update includes a feature on Morgan's Raid. Find out more at http://emergingmediainitiative.com/updates/may-2011/. The Update includes the following video in which I talk about the project and make a push for broader changes in higher education to promote this kind of work.

Morgan's Raid Spring Team

A photo of the Morgan's Raid Spring team, taken at the Ball State University Student History Conference.

Morgan's Raid in the Indy Star

Yesterday's Indianapolis Star had a feature on our playtesting of Morgan's Raid at River Birch Elementary in Avon, Indiana.

Here's the link again, in case I was too subtle above. Don't make me write "Click me."

Morgans Raid: Sprint 10

Last Friday was the end of Sprint 10 for the Morgan's Raid team. Here's the burndown:

In Sprint 10, the Sprint Planning meeting was held while I was away at the administrators' retreat, so the students had complete authority. There were a lot of small user stories this sprint, and there was confusion between me and the team regarding whether certain stories were committed but not on the sprint burndown, or whether they had brainstormed some tasks for non-committed user stories. I'm not sure that the burndown chart is accurate: the first dramatic dip may have been a miscalculation. The real lesson here, then, is one of communication: I don't think we talked about the phenomenon adequately until two weeks later at the Sprint Retrospective.

Speaking of the Retrospective, I think the team continues to do great work. I feel that there is a real team identity and that they trust each other. They're really a fun group to work with, and I am saddened when I am called away from them to work on mundane tasks such as committee meetings or advising.

Today, we're heading out to an Indianapolis-area elementary school to do some end-user testing with our current prototype. I'm quite excited about it, and word is that there will be press from both BSU and the Indy Star there. The only downside of the story comes from my efforts this morning to clean up just a few loose ends before the playtesting. There is still a lot of cruft in the codebase, things that should be embarassing but I fear the students still either (a) don't see as ugly or (b) don't consider it worth fixing. Here's an example: there are four different cinematics in the game and they are all driven completely by YAML configurations. Despite the fact that each only differs in which configuration is loaded and what follows the cinematic, folks last semester implemented four different classes for these features via copy-paste coding. In each one, mouse clicks were incorrectly handled by polling in the update method rather than by overriding mouseClicked. To fix the bug wherein mouse clicks were sometimes not recognized, I had to go change this in four places. Since we are literally hours away from end-user testing, the last thing I wanted to do was introduce any risks into the system, but you can bet that before the weekend, someone is going to fix this.

I was inspired by Martin Fowler's recent article on the Tradeable Quality Hypothesis, which can be summarized by the statement, "You cannot trade quality." In the Sprint 10 Retrospective, we talked briefly about how I felt that the students were developing some sense of programming aesthetics, a skill or perspective that I have been contemplating for some time. Working side-by-side with students on design, analysis, and development still seems to be the best way, although it does not scale, and my other job responsibilities are not always conducive to this end.

Morgan's Raid, Sprint 9

Sprint 9 ended last Friday, and the team is doing great. Starting with the Spring semester, we are not using Google Docs for the Product and Sprint Backlogs, since now we have a persistent space in which to work. Since I don't have an electronic log of activity, then, it has become important that I archive a few of the details here.

In the burndown chart, green is steady progress and blue is actual progress. The bump around Monday and Wednesday coincides with the big ice storm, and the fact that we only had such a small bump is a testament to the team's commitment. A few team members were able to come to campus that Wednesday afternoon to hammer out the most ambitious part of the sprint: the implementation of the new raiding system. Others continued to work from home, using email and chat to keep in touch.

The team's total estimate of hours ended up being fairly accurate, although the specific allocation of estimated hours to tasks was off by quite a bit. The team recognized this and agreed to draw upon this experience in the Sprint 10 Planning Meeting. This meeting happened on Monday, but I still know nothing about it since I was at the strategic planning roundtable retreat. I left the team with a prioritized Product Backlog, and I'm eager to see how they chose user stories and broke them down into tasks.

Morgan's First Sprint of Spring

Last Friday was the end of Sprint 8 on the Morgan's Raid project. This was the first sprint of the Spring semester. The "closers" are a team of eight CS majors and our one Honors Fellow from Art. The team were selected from among the 25 developers in Fall's CS315 class. These eight were among the top students in the Fall, and not all were from one team. I am not loaded for running the project this semester, and so I had to limit the number of students I could take on to what I could comfortably manage in my regular assigned research time.

During Sprint 8, we crossed the 1000th changeset, and as of this writing, we're at revision 1037. We had a pizza party at the end of the sprint to celebrate, and I promised the team we would do it again on every order of magnitude. I wonder if Papa John's will still be having their $10 large deal when we hit 10,000?

For Sprint 8, we budgeted 80 hours, assuming each student would work 10 hours per week and that most work would be done in pairs. Unfortunately, I had forgotten about Martin Luther King Day when we did the planning meeting, and so we were actually overcommitted when one considers that we lost a working day. Still, the sprint went quite well, and I think the team did a great job of estimating their tasks, including difficult design tasks such as revising the raiding system through multiple paper prototypes.

Since we have a dedicated space (hooray!), we moved off of Google Docs as a platform for managing the Product and Sprint Backlogs and are now using a whiteboard and Post-It notes. I think the only feature we miss from Google Docs is the automatic updating of the burndown chart based on updated estimates of effort remaining. (This also gives me an incentive every two weeks to post our burndown charts here, so that I don't lose my digital copies.)

The other major change we made was to modify the Sprint Backlog format. In the Fall, teams broke down user stories into tasks and then marked their estimates of hours remaining after each working unit. Whether a task was not yet started, in-progress, or finished was implicit in the numeric value and slope. One of the prominent weaknesses articulated by the team in last semester's retrospectives was the need for more formal validation, and so this sprint, we have a backlog in this format:

User story	Tasks not yet started	Tasks in progress	Requires validation	Done

Formalizing the need for validation helped in Sprint 8, although in the retrospective, we realized that we needed more careful articulation of whose validation was required. With multiple product owners and tasks of varying technical complication, it was not always clear who was the appropriate person to contact. However, I do think that losing Monday to MLK day was a major factor here.

For the love of Morgan

On Friday, I had to leave the Morgan's Raid team meeting early to join up with my colleagues on the Future of Education Task Force. I stopped in the office today to get some work done and found this note on my door.

I had been a little down on Friday, and I remember saying as much to the team. Lots of work to be done, including a wicked problem for the Task Force, a chapter to write, a course to plan, and the anniversary of a son's birth to celebrate. The team was listening. Good people, these.

Civilization, War, and Learning

Those of you who follow my Facebook posts have probably figured out by now that I broke down and bought Civilization V. It's the latest by Sid Meier, whose Pirates! is one of the best games I have ever played, but that's a post for another time. For those who are not familiar with the Civilization series, they are turn-based strategy games that follow the development of civilization from ancient times up to the modern age. Although they are a hallmark of PC turn-based strategy gaming---and I love turn-based strategy games---I have never played any games in the series until now.

Last night, I finished my first game of Civ V. I used the default settings, which were for beginning players, and I happened to be playing as the British Empire. My civilization developed much faster than the opposition, probably more because of the low difficulty setting than any clever strategy of mine. There are multiple ways to win the game peacefully: scientific leadership, diplomacy, and cultural development. Because my civilization was advancing so much more rapidly than my opponents, I took the classic gamer's optimization approach: military victory. After all, why wait for my inevitable cultural victory when I can just send my superior army to crush the opposition and annex their land to mine, thereby winning the game?

As my army crushed the opposition, the in-game music turned from pleasantly ignorable and ambient into rather dark and sad compositions. Every time I declared war and sent my troops over their borders, the music set the mood not of a glorious conquest, but of grief and despair. As my navy bombarded coastal cities, they caught fire, and I could hear the screams of civilians. As I destroyed the last city of the Indian empire, Gandhi appeared on the screen and congratulated me on destroying a kind and peaceful people. As I defeated my last opponent, I received the end-game screen, an image of WWI-era soldiers marching over a barren land, and again the music set a somber tone.

Here is a great example of the power of learning in games, following the themes in Koster's Theory of Fun. The game is clearly designed to be fun, and there is a sense in which my military victory was enjoyable, but even more than that, it made me think. The formal elements of the game (the rules) combined elegantly with the dramatic elements (the music and story) to produce a unique experience. Most games I play follow a single hero who single-handedly destroys the vanilla-evil opposition, and there was much rejoicing. In Civ, I actually felt guilty for destroying these other civilizations just so that I could "win."

I hope to be able to draw on this in my current efforts with the Morgan's Raid game (as well as the potential Underground Railroad project), where there is a similar lesson we wish to subtly teach: although the player takes the role of John Hunt Morgan, he is neither inherently a hero nor a villain, but the Civil War was undeniably an ugly and painful thing. We have an interesting design constraint in the game as well. Since it is designed for 4th grade students to play in schools, it's likely that it will be played without music, in crowded labs or during free time. It was the somber music of Civ that moved me the most; I can only wonder what would have happened if I had been playing without my speakers on, since I can never go back to my first experience.

Demon JHM: Final boss of Morgan's Raid

I stopped by the lab to see if any of the 3:15 Studio team members needed anything, and the room was empty except for this.

I think I have to go rewrite the design document now.

Two Sprints with 3:15 Studio

We are now two sprints into the CS315 game programming class. I have not updated this blog as often as I intended, but I suppose that means I've been busy, which may even imply that I've been productive. The advantage of being healthy in a house full of sick people is that everyone else is sleeping, and I still have the energy to do some writing.

I am a little surprised to see I haven't actually written much about this class since before the semester started. We are in the middle of the fifth week of the semester, but let me start by explaining what happened in the first week.

One week of training

The students were introduced to the "course" by being told that it was not a conventional course at all. Rather, the students were in an orientation week for their positions working for 3:15 Studio, and their project was the implementation of a game based on Morgan's Raid. They were told that the orientation and training would last one week, and we'd move from there right into production. I was also explicit in saying that they were expected to work ten hours per week. This is something I've started telling all of my classes, based on the arithmetic that 40 hours per week is "full time" and 12 credit hours is "full time." With this class, though, it was not a recommendation to allocate that much time but a statement that this was the amount of work required. That is, from day one, this was presented as a situated learning experience, in which the students comprise one studio under my direction.

The rest of the first meeting consisted of introducing the game design, the stakeholders, and the historical context. The students were given a quick introduction to Mercurial and the MercurialEclipse plugin, and they were shown how to upload an image to a shared repository. Their first assignment, then, was to upload a portrait to a shared repository to help us get to know each others' names.

The second day (Wednesday) was a breakneck introduction to test-driven development, entity system architectures, pair programming, and Scrum. This was done in a lecture-oriented style, primarily as a means to maximize throughput. It was expected — and experience has shown — that not much of this was retained by the students, but it did help them build a mental framework of what level of rigor was expected. This resulted in the studio size decreasing from thirty to twenty-five, which I see as a positive step: students who were not willing to make the investment elected to choose another course. (It is an unfortunate phenomenon that, even at the 300-level, students mistake "Game programming" as a light and fun elective, when in fact, it is grueling and fun.)

The third and final meeting of the week (Friday) was mostly devoted to team formation and task allocation. Based on the number of registered students, I directed them to form four teams. The teams were formed primarily based on pre-existing social networks, at least according to my informal observations. At one point, there were three complete teams formed, but a headcount revealed that two students had not actually been incorporated into a team. Two of the teams shed members to join these two to be the final team, whom I will reference later as "that team I mentioned before."

For the first sprint, I wanted to give the students an "easy win" in order to build morale, and I wanted to ease them into Scrum, entity systems, and TDD. Based on this motivation, I set up a product backlog consisting of user stories that were all at the task level. That is, I had pre-sliced problems into tasks achievable by pairs of students. These were, in a sense, not proper product backlog items, since many had to do with software architecture and not anything that has value to the stakeholders, but to me this was a reasonable accommodation in my circumstances.

Sprint One: Two weeks

The first sprint was a success. All of the teams delivered their product backlog items (PBIs) modulo some miscommunication and minor revisions. Most of the tasks were fairly straightforward implementation tasks, the sort that would take me under an hour, but that I expected the students to take much longer since the learning curve was so steep. It's worth mentioning that the team I mentioned before happened to pick up the most difficult of these tasks. Given that the team was made up of a hodgepodge of students as opposed to a motivated group of friends, I was concerned as to how they would handle it, but this team came together in an exemplary way to solve their problems. (More on that in a later blog post, perhaps.)

There was a case around the middle of the sprint where some students broke the build — did I mention we're also using CruiseControl for continuous integration? I took the opportunity to shame them on the studio mailing list, and in that message, reminded everyone to be careful about what they code they push. I emailed these students privately and thanked them for being good sports about being the first to break the build, dooming them to be my sacrificial lambs for the good of the team. I knew these guys, and I knew they could take it. Good job, men. Since then, the only real "breaking" of the build has dealt with images being too large and non-portable Java code that works on only some operating systems.

The production portion of the sprint ended on a Thursday, and the next day we held a combined Sprint Review and Sprint Retrospective. This is really a place where the University's scheduling system is a challenge, since we had to do both in the space of 50 minutes. We could have used more time, but we made the most of the time we had. The Sprint Review revealed one of the major weaknesses of the product backlog design: because the PBIs were primarily architectural, I was the only one of the three Product Owners who could appreciate that progress had been made. The programmers and I were delighted just to get a window open with anything in it, but I think my collaborators expected a little bit more. I assured them that this was a necessary step to get the students up to speed.

The Sprint Review was amazing. We had two timeboxes: ten minutes to discuss what went well, and ten minutes to discuss what could be improved. We could have kept on going with our list of successes, and I could feel the excitement and morale in the air. As for the things to improve, many were very simple to address. We left the meeting on a high — helped by Concannon's chocolate chip cookies. One of the important tips I got from Clinton Keith's book was to take the time to celebrate at the end of a sprint, but with a mix of under- and over-age students, cookies seemed like the safest bet.

After this meeting, I met with my co-PI and we reprioritized the product backlog. Moving into the next sprint, we consciously revised the PBI format to deal strictly with those things that add value to the product owners.

These are the burndown charts for the four teams for Sprint 1.

I used Scrum a few semesters ago in game programming, and since then I've studied it more and been applying it with more care. However, my recollection is that it took us several sprints to get anything approaching the level of steadiness shown in some of these burndown charts. Some of the skips are interesting, since they show places where teams thought they had finished their tasks, then found that someone else pushed code that broke theirs or overwrote theirs—casualities of learning Mercurial—and then had to do clean the repository and get their solutions back in place.

Sprint 2: A 1.5-week short sprint

Sprint two ended today, and it was a short sprint due to weekend conferences: both me and the other lead investigator on the project would be away, and so we couldn't do a two-week sprint as planned. Instead, we decided to have Sprint 2 be a short one followed by a slightly longer Sprint 3.

I had overestimated the diligence of my students when, the weekend before the Sprint Planning meeting for Sprint 2, I emailed some comments on the revised product backlog and sprint backlog formats. As mentioned above, I revised the product backlog into items that required slicing by the students as opposed to pre-sliced tasks, and so I had also revised the Sprint Backlog format so that a PBI could be copied in and individual tasks listed below it. At 2pm we started the Sprint Planning, and it quickly became clear that the students had not appreciated this difference. Teams quickly started committing to PBIs, before they had taken the time to see that these were much heavier PBIs that needed breaking down. I hoped they would see this, but when I saw that teams were also changing the sprint backlog format to match the old one, I interrupted and explained what they should be doing: pulling down a PBI as a team, breaking it into tasks, committing to and estimating for those tasks, and then only committing to another PBI if there was excess capacity within the team.

The unfortunate result of this was that, rather than having a contiguous block of high-priority PBIs selected for the sprint, it was a bit of a toss-up. There was not time in our 50-minute timebox to start over, and so some rather important items were left unclaimed. Also, the teams shied away from high story point PBIs for fear of complexity in a short sprint, and I'm not sure that was unwise.

I felt a little more tension this sprint as more students had to use pieces created outside their team. Also, as I worked with teams, I noticed the overall quality of the code was getting worse. It's not so bad as to be unredeemable, but there are some code smells that would make a seasoned professional reach for a handkerchief. The problem is, of course and again, that it's a team of novices who cannot recognize code smells.

Even though the production was supposed to stop yesterday, I helped one team pull a last-minute victory before the Sprint Review and Retrospective today. The review went well, and my other two Product Owners agreed that it was good to see something actually working, rather than just looking at code that only I could appreciate. There were a few more loose ends this sprint: not all of the PBIs were completed according to their conditions of satisfaction, although this was fairly minor. One teams had committed to PBIs on the product backlog that it had neglected to copy to the team's Sprint Backlog, but I think they were embarrassed enough at this that they would not do it again. Much of this was fallout from the rough Sprint Planning meeting.

During the Sprint Retrospective, the students were much more pensive. No longer were they chomping at the bit to shout out the first positive thing that came to mind: instead, their contributions were more considered. This is natural, I think, and it shows a maturation of the studio. I was glad to see that inter- and intra-team communication, although mentioned as a success in Sprint 1, still was listed here, because communication is the key to keeping this studio together and making the project succeed.

We are currently discussing via our mailing list a few ways to address shortcomings in the system. One of the positive outcomes of this is that now, I think the students are all hungry for more information about software design and refactoring. They are feeling the real pain of real software development. This is very different from other teaching experiences—even my other class—where I have tried to teach the solution without the students really feeling the problem. It looks like we'll have some Community of Practice meetings in which I will lead code reviews or refactoring/redesign sessions. The students are hungry for it, and that should help them absorb some rich ideas.

Because I have them, here are the Sprint 2 burndown charts. They are in the same team order as the previous, so feel free to compare. My only significant comment about them is that, despite the fact that the teams were slicing up PBIs themselves for the first time—and many of them have never done this and never worked on a team before at all—these are still remarkably steady.

Onward to Sprint 3

While I am at the 2010 Consortium of Computing Sciences in Colleges Midwest conference, my students will be responsible for running the Sprint Planning meeting for Sprint 3. I have sorted out the highest priority PBIs, though I still need to do some cleaning up further down the backlog (which, incidentally, currently contains about 85 PBIs). I am confident that they will do a fine job in my absence.

This has been a fantastic teaching opportunity for me. I have invested more time and emotional energy into this project than any other venture since my doctoral dissertation, and I think the students appreciate being involved in this experience. My one niggling fear is that the whole experience cannot be replicated without expending this herculean effort each time, but I will leave sustainability of immersive learning for another writing.

Planning Poker with Undergraduates

I have spent many hours working on the product backlog for Fall's Game Programming (CS315) class, in which the students will implement the Morgan's Raid game. Originally, I specified the story points for every user story, but I was concerned that my estimates were not representative, especially since my teams were comprised entirely of novices who are familiar with neither the technology nor architecture.  Following the advice in Clinton Keith's Agile Game Development with Scrum, I decided that a planning poker session could be the best approach for reliably determining story points. Briefly, in a planning poker session, each participant has a hand of cards, and each card has a number on it. For every user story, the participants choose and then simultaneously reveal the number of story points they chose, repeating until consensus is reached. This facilitates communication among stakeholders about the product backlog.

My backlog currently has about 70 user stories, about 25 of which are high priority. An ideal planning poker session would contain stakeholders with areas of expertise relevant to the project. When dealing with undergraduates, there are no experts, but the gulf between novice and expert itself provides a motivation for planning poker. Although I work with undergraduates regularly, I still find that I often make mistakes when estimating how long various tasks will take them, especially when integrating ideas that I have internalized but that are new to them. In a project involving a combination of object-oriented and entity-oriented design, Scrum, continuous integration, and unit testing --- all of which are new to the students --- there are ample opportunities for estimation errors! A planning poker session, I figured, could help us determine more accurate story points than if I did it myself. This would also be an excuse to explain the various parts of the experience to a subset of Fall's class, giving me practice and seeding the class with students who have already seen some of the ideas.

(A parenthetical story: Last night, my wife asked me about this morning's meeting, and I told her briefly what it was about. My brief explanation was completely insufficient, so I explained to her some principles of agile software development, Scrum, continuous integration, and planning poker. It seems that, despite the effort I have invested in preparing for the course, I only ever really explained it to her as "working on my spreadsheets." Explaining all of these things to her --- who has as much experience with these ideas as many of my students --- was a great experience for me. This also means that she probably doesn't read my blog, so I can safely write about her here, as long as we all keep our mouths shut.)

I sent out an invitation to some of the students I know who are signed up for CS315, using Doodle to find the time that most could meet. I wish I could have had them all, since I chose them for their breadth of experience and perspective, but the best I could do was Tuesday morning with four of the invited. This morning, one informed me he could not attend, and another did not show, so the meeting went forward with me and the two students. Not counting coffee and bagel time, we worked for about 90 minutes on the backlog and covered all the high priority items. I don't know anything about the programming skills of these two students, but I will say that if I have a class full of students as clever and motivated as them, this semester will be fantastic. As one might expect, the first few were a little rocky as I had to explain some of the background and we had to get a feel for the abstract measurement of story points. We quickly hit stride, and the story point negotiation revealed places where more detail or more stories were needed.

It so happens that all three of us at the meeting are gamers, and it was interesting to engage in planning poker as a cooperative game, especially given my recent interest and readings on software development as a cooperative game. Having this meeting face-to-face, it was fun to choose point values and hold the card face-down while waiting for the others to choose a value: there was the tension of anticipation, the climax of revealing values, and verbal and non-verbal negotiation, and the joy of consensus. In fact, in the few cases where we all chose the same value the first time, it definitely felt like a "win." The experience was a game in Huizinga's sense, especially in the construction of a time-boxed community of players in a shared experience. Qualitative technical communication researchers, take note for potential future research opportunities!

I am confident that the values we determined are reasonable and will give realistic measurements of teams' velocity. Based on this positive experience, I plan to have another planning poker meeting with some volunteers once we make progress on the high-priority user stories. I hope that the experience was as enjoyable for the students as it was for me. My only regret is that I did not take a picture of my awesome planning poker cards before I left, but they are in my filing cabinet for another day. Now if that's not reason enough to come back for more blog, I don't know what is.