The ZP Agile Game Workshop introduces a game project to effective Agile development techniques. The workshop specializes in techniques that large game development teams can adopt rapidly with minimal thrashing.

The workshop installs the following Best Practices at your game development site:

• Burn-Down Charts - publish metrics and goals in charts that rate progress
• Customer Tests - enhance the daily build system with a full-featured test server
• Frequent Releases ("Scrum") - deliver a new version of the game each week
• Pair Programming - the most difficult code changes require proactive collaboration
• The Planning Game ("Scrum") - each week the team declares a short list of goals

This workshop does not address the technical Agile practices, such as Test Driven Development, Refactoring, Emergent Design, or Continuous Integration. Complex game projects present formidable obstacles to "unlearn" their current implementation techniques. Leaving the current techniques' benefits behind would add risk. Our workshop focuses on the Agile techniques known to improve processes with minimal technical support. This process improvement, in turn, will provide the framework for further process changes.

The workshop consists of three phases:

• Phase 1 - Checklist - prepare for the coaches' arrival
  • Daily Builds
  • Pair Station
  • Test Server
    • Command Lines
    • Log File
    • Trigger
  • Requriements Backlog
• Phase 2 - Iterations - coaching sessions to begin metrics collection and planning
• Phase 3 - Tracking - monitoring the metrics and plans over time

Phase 1 - the Checklist: The project team commits to prepare for the ZP coaches. This ensures the coaches do not need to spend too much time setting up the hardware and software. The checklist items are all inexpensive and available to any programming shop

• Daily Builds. A build server should should automatically rebuild everything, each time developers change its source and commit it to a version controller. This build system should be prepared to trigger test runs, as specified below
• Pair Stations. At least two workstations should be configured with...
  • two chairs
  • enough horizontal room for two people to sit at them
  • two keyboards & mice
  • a similar desktop environment (no weird keymappings or themes)
  • a complete game development environment
  • a shared username (such as "PairStationTwo")
• Test Server. A dedicated computer should be ready and available, 24/7, to run automated tests
  • Command Lines. The Game EXE (in a Win32 build) should be configured to accept command lines with the same meaning as those specified in the test server paper. The command lines may use any names and syntax, so long as the meanings are the same. If the game cannot yet read command lines, the team should prepare a script or batch file that sets up these configurations correctly, then invokes the tested game
    • --levelname Q - teleport the hero to this gameplay location
    • --runfornframes 99 - start the game, render this many frames, and gracefully shut the game down
    • --randominput - the game should generate random controller input, as if a manual tester were rocking the (appropriate) joystick controls frantically and obliviously. This mode might combine with a "god mode", to prevent the hero from fragging her or himself
    • --runscript Script.lua - evaluate this high-level gameplay script during a run
  • Log File - each run should write a log file with all suspicious conditions reported inside it. Each entry should support a common . The log file should reflect the game's build number, the data file's build  number, and the command line configurations for this run
  • a Trigger should communicate build events from the build server to the test server. ZP coaches will lead a project test engineer to upgrade this trigger to run all the tests. For a simple trigger, the build server's final build script should change the modification time of a file on the test server. A script on the test server then reads this file's every second, and runs another script each time it changes. The project site must commit to maintaining these scripts, so they may be as simple as possible
• Requirements Backlog. A list of outstanding requirements should exist and be prioritized by the stakeholders. This will form the basis of our Planning Game, from which we drive the implementation of the game.

Phase 2 - the Iterations: Now that the project site has assembled the tools, ZP will send coaches to the site, to run the team through one week of Agile development, from Monday to Friday.

On Monday morning the team, a game designer, a test engineer, and the ZP coaches will run a Planning Game, and write the "User Stories" for this week's iteration based on the top week's worth of tasks in the backlog. The team will commit to testing and implementing the stories, based on their estimates. Each day, the ZP coaches will recommend adjustments for any issues that arise from learning these techniques.

The site test engineer will pair program with a ZP coach to build the test server, from the above ingredients. This process ensures the team can maintain and improve the test server after the ZP coaches leave.

The team will agree on relevant metrics to extract from the build and test servers, and ZP coaches will configure an automated daily chart (using GNUplot or similar). The team will print and display this chart at relevant intervals.

A ZP coach will train the team's management on effective methods of keeping the Requirements Backlog up-to-date, how to handle change requests, and how to project forward to get an idea of how the outstanding requirements fit into the schedule and get an early view on any changes that might be required to hit any "hard dates" by which the team is constrained (such as E3).

On Friday, the team will deliver a working version of the game to the game designer, and will demo its new features. This demo will lead to the next batch of User Stories in the next Planning Game.

Phase 3 - Tracking: Adapting these processes will stress teams challenged with writing complex projects. ZP coaches will track the project's general health via e-mail and chat, and will return 3 times for 1 day follow-up sessions. These must be scheduled 15 days in advance, and should occur generally 1 week, 3 weeks, and 6 weeks after the Iteration session.

The ultimate intent of this process is obviously not to recite the Agile mantras. Our workshop leads a team through a series of experiences intended to transform their process, and rapidly provide meaningful metrics indicating where and how a team improves.