Wednesday, September 30, 2009

San Francisco ScrumMaster Course November 10-11

Are you looking to energize your teams, reduce costs and increase performance? Has crunch, missed schedules and budgets become harder to avoid? Scrum and agile practices have helped many studios improve product development and the workplace environment.

Learn to establish and improve Scrum in your studio by becoming a ScrumMaster in the only workshop that focuses on game development from the Certified Scrum Trainer with 15 years of game development experience.

This two-day course provides the fundamental principles of Scrum through hands-on experience and interactive project simulation. During the course, attendees will learn why such a seemingly simple process as Scrum can have such profound effects on an organization.

Attendees learn to apply practical, project-proven practices that have worked for numerous video game projects
  • The essentials of getting a project off on the right foot
  • How to build a product backlog and plan releases
  • How to help both new and experienced teams be more successful
  • How to successfully scale Scrum to large, multi-continent projects with team sizes in the hundreds
  • How to help producers, artists, designers and programmers work together effectively
  • How to work with publishers and others outside the team who may not be familiar with Scrum
  • Tips and tricks from an instructor with 15 years of game development experience and 5 years of experience applying Scrum to game development

Participants who successfully complete the course, will become Certified ScrumMasters through the Scrum Alliance and receive a two-year membership in the organization where additional ScrumMaster-only material and information are available.

Pricing and Availability

The Certified Scrum Master for Game Development Course is being held just prior to the IGDA Leadership Forum on November 10th-11th at the SF Airport Marriott. The course has limited seating and is available for $1500 by visiting
Discounts are available for those attending the leadership forum or groups of four or more.

More details for the course material can be found at

Wednesday, September 23, 2009

Development cultures

An interesting thing about traveling around the world is to compare the subtle differences between cultures. Besides hearing people's views and opinions, I love to observe things in their environment. How people drive, the graffiti, the amount of litter, the colors they choose are all interesting. As I type this, I'm in a nice hotel that is very clean and has had a lot of attention paid to the decor. However, half the stuff seems broken or poorly designed for use. Most are little things. For example, I had to go down to the desk to ask how to hook up the ethernet. The rooms don't have guides. "Oh, that jack is on the bottom of the phone" I was told. I then discovered that there was no phone. "Oh, some rooms don't have a phone". I was moved. Again, more questions, but the phone was broken. So it was back to the front desk. This went on and on. The staff seemed used to the questions and there were a lot of them being asked. I hear that this is the norm for other hotels around here.

Interesting contrasts exist for studios developing games. The differences in cultures between studios in the same town can be greater than those in separate countries! For example, there is often a dominant discipline in the building, which manifests itself in the tool chain. There is a level of tolerance to defects....sometimes little tolerance, sometimes a lot. There is a wide variety of process discipline and who "owns" the process.

The bottom line is that there is no single superior development culture. You can't look at any of these studios and predict which will make the hit game based on culture alone. You can certainly predict which one is going to make the game at lower cost with less crunch and stress, but those benefits don't get printed on the back of the box.

Sunday, September 20, 2009

Agile and Fixed Ship Dates

A common impression about agile is that it does not allow games that use it to ship on a fixed schedule. The impression is based on the idea that agile teams don’t plan, but simply iterate with a very short horizon - they just don’t know when the project will end!

Although most games have a ship date, many of these are considered “firm” rather than “fixed”. Firm ship dates are established by publishers to fit portfolio or budget projections. A firm ship date will drive the project, but if it desperately needs another month or so of work to achieve far better results, it won’t be a disaster to slip the date. Fixed ship dates, on the other hand, are critical for the success of some games. Examples of games with fixed ship dates are those that must ship simultaneously with a movie release or games like Madden Football, that must be on shelves by the start of each NFL season. The penalty in lost sales for missing these dates is major.

How is a project with a fixed ship date managed differently from one that is not? Mainly it is the way risk is handled. Risk is uncertainty about what a team is creating and how it is going to build it. For example, if we want to dedicate 20% of our project budget to creating a cooperative online deathmatch mode with AI opponents for our game, a few of the uncertainties might be:
  • Will the AI work online?
  • Is 20% of the budget budget enough to create a fun and complete experience?
  • Will problems in other areas delay work or take people away?
The list can go on. Any one of these can threaten the project’s schedule and result in the feature being dropped after almost 20% of the project’s budget has been spent on it.

So how is risk handled? Developers often try to plan and schedule their way out of risk by creating exceedingly detailed plans that attempt to identify the solution to every foreseeable problem. Unfortunately, since the danger lies in what a team does not know, it’s certain that the tasks required to overcome risk will not be identified up front. The best way to handle risk is focus on answering the unknown: creating knowledge.

Creating knowledge and value is important for any project, regardless of the ship date. For projects with fixed ship dates, the prioritization of work to reduce risk is a bit higher. For example, if a movie-based shooter game with a fixed ship date has to decide between shipping six months after the movie’s release or dropping online gameplay, they will be more likely to drop online. A game that is not based on such a license, which instead has a firm ship date, is more likely to be delayed to ensure the feature is included.

So back to the original question: Does agile aid or impede a project’s ability to achieve a fixed ship date? Executed properly, an agile project has significant advantages over other methods. There are two core principles behind this advantage:
  • Prioritizing to create knowledge and reduce risk. Focus on delivering high value and addressing risk early. Fixed ship dates only allow a project’s staff or the scope to vary. Increasing the number of developers on a troubled project usually doesn’t help. Brook’s Law says that “adding manpower to a late software project makes it later”. The same applies to game development. The best option is varying the scope, or feature set, of the project. Identifying the best features that fit within the schedule is critical for the success of a game with a fixed ship date.
  • Not postponing debt. Frequent integration, immediate defect correction and maintaining target performance will prevent late surprises that require rework and delay. When projects with fixed ship dates postpone critical work to post-alpha, they often meet with disastrous results.
The tools for applying these principles are the product backlog and the “definition of done”. The product backlog clearly lays out the order of work to be accomplished. The order is determined by the priority of features on the list. Usually this priority is determined primarily by the value of each feature to the consumer, but for a game with a fixed ship date, the element of schedule risk must often take precedence over value. An example of this is having a team do an early spike to mock up a full level. This would create early knowledge about the level dimensions to better refine the production requirements and resources. Doing this constrains some of the options for emergent gameplay, but for a fixed ship-date it might be necessary to know this information sooner than later.

The “definition of done” is the agreement between the developers and the product owner about how much each feature must achieve before it is considered done for the sprint. If a game must ship on all platforms on the same day as a movie release, a product owner might include “running on all the platforms” as a part of the definition of done earlier in the project than they normally would. While these additional criteria may slow teams down, especially if the platform technology isn’t fully mature, it will accelerate improvements there and create more knowledge about the risks of those platforms earlier.

Agile and long-term planning
Agile methods don’t attempt to plan away uncertainty with large documents, but they also don’t ignore it. They simply tailor the practices to the different level of uncertainty over time. Planning for the short term , such as sprint goals, are done at a far higher level of detail than most. Planning for medium range goals, such as release planning, is less detailed, but receives continual refinement. Long range planning for ship dates, production scheduling, etc are also continually refined and influence short-term planning. For example, an agile plan won’t say “production will start on September 14th” a year in advance. It will refine a range of times over the course of pre-production. The reason is that not only will we gain knowledge about production in pre-production, but the debt itself will actually change! As we discover or even change some of the features of the game, they will alter the amount of time assets will cost to be produced. I have an entire chapter in my book dedicated to long-term project planning, so make sure you buy a copy in early 2010! ;)

Too many times, fixed ship dates result in little innovation or a poor game that must be shipped before it’s been properly polished. Games released with movies have long had a reputation for low quality. This doesn’t need to be the case. By eliminating the waste of dropping features at the 11th hour, after months of work has been dedicated to them, is a good place to start.

Sometimes a fixed ship date is impossible to achieve. A risk-based approach for developing completed features will not work miracles, but it will expose the bad news sooner than later.

Sunday, September 13, 2009

Sunday, September 06, 2009

Attending the Montreal Game Summit in November

I'll be presenting at the Montreal Game Summit this year, talking about Lean Production. It's a great conference in a great city. Someone with a camera cornered me there last year and shot this video. After seeing it, I vow to never go beardless makes me ramble and say things like "lean is a branch of agile"! ;)

It looks like the Alliance numérique is up for hosting another Certified Scrum Master for Game Development course just before the summit. I'll have an announcement for that soon.

Friday, September 04, 2009

Certified Scrum Master for Game Development course in San Francisco on November 10-11

Announcing a two day Certified ScrumMaster for Video Game Development course in San Francisco at the Airport Marriott on November 10th & 11th, just prior to the IGDA Leadership Forum.

This two-day course not only provides the fundamental principles of Scrum, it also gives participants hands-on experience. This course puts theory into action through extensive use of exercise and a project simulation. All exercises and discussions are specifically tailored for those working in video game development.

During the course, attendees will learn why such a seemingly simple process as Scrum can have such profound effects on an organization. Participants gain practical experience working with Scrum tools and activities such as the product backlog, sprint backlog, daily Scrum meetings, sprint planning meeting, and burndown charts. Participants leave knowing how to apply Scrum to all sizes of projects, from a single collocated team to a large, highly distributed team.

The price for the course is $1500. IGDA members and non-members attending the Leadership Forum on November 12 & 13 receive a discount.

More information about the course is here.
Register here.