Friday, January 29, 2010

Congratulations Bioware!

I just received my copy of Mass Effect 2, developed by Bioware in Edmonton, Canada, a client of Clinton Keith Consulting.

I met the developers of Dragon Age late in the game's development and was bombarded with a wide range of insightful questions about Scrum and agile in general.

The ME2 team I met was talented, well led and experienced in using agile practices (having adopted agile during ME1).  They explored lean practices for ME2 production and spoke about them at GDC.

Bioware has always been at the forefront of exploring ways to improve their development processes.  Talent, vision, focus and leadership are in abundance there.   They understand that Scrum is merely a tool for leveraging those attributes and that continual improvement is a necessity.

Congratulations to both teams and Bioware!

Thursday, January 28, 2010

Agile Video Tip - Applying Kanban to Support Teams

New 5-minute video up on my website (at the bottom).  Applying Kanban practices to support teams that use Scrum.

Saturday, January 23, 2010

Agile Game Development Video Podcast

I think graphically, which is why my book has lots of figures. Now that the manuscript for the book is about to enter production, I've decided to start producing short (~5 minute) video podcasts (vodcasts?) that contain tips about using agile.

You can find my first one, about using Scrum to pull work rather than to push it through a sprint at the bottom of my home site.   Let me know what you think and how it can be improved!

Tuesday, January 19, 2010

Agile Game Development Survey

Gamasutra has asked me to write an article about the "state of agile in the game industry", but it's best if that knowledge comes from you.

Take a short survey! 

The results will be compiled and included in the article.

Thursday, January 14, 2010

Announcement: Lean Software and Systems Conference, April 21-23

I'll be attending the Lean Software and Systems Conference in Atlanta this April (21-23), presenting this session:

Kanban for Video Game Production

The session will describe how Lean Production and Kanban has been applied to game development. Lean principles and Kanban tools have been used by a number of developers, including the presenter, to slash production costs by over 50%. As a complement, or replacement, to Scrum, Lean/Kanban provides predictability, transparency and optimization for complex game production.

Although there is a strong software bias to the conference, anyone who is implementing or planning to implement Lean/Kanban practices in their company for any product type will benefit from attending.

Monday, January 11, 2010

Agile Game Interview - "Simplicity Is Hard"

The following is an interview with Chris Ulm, CEO of Appy Entertainment about iPhone game development and using agile.

Clinton Keith: Chris, tell us about iPhone game development:

Chris Ulm: iPhone game development is faster, more competitive and far more unforgiving than any other platform I have developed for. On the plus side, original ideas can become innovative games very quickly. On the minus side, the three month development cycles and low retail prices mean that budgets are tight and we must be ultra efficient. We've found that using agile methods have allowed us to prioritize the scope of our small projects and work effectively with contractors all over the world.

Our iPhone projects are quite complicated with third party advertising APIs, Bluetooth multiplayer, social network and email wireless connectivity. We allow users to use their photo albums and their iPod music as essential aspects of gameplay. We have integrated the OpenFeint social network in all of our games, allowing users to browse leader boards and compare scores with anyone playing the game, anywhere in the world. All of this complexity needs to be built quickly and for a price that starts at free. Without agile, it would be very easy to lose sight of your end goals.

CK: What's different about being agile for iPhone games

CU: Unlike most agile projects, on the iPhone you can LITERALLY work for two weeks and "ship" what you have as a finished product. So knowing when to ship is the most important thing.

A unique challenge for the iPhone is knowing how much to give. People expect a LOT for $0.99. The number one complaint about Zombie Pizza was that the game was only three hours long -- three hours for .$099!

CK: What do agile iPhone projects look like?

CU: Strong vision led by white-boarded interface description and a minimal document to kick off the concept. Big huge whiteboards are everywhere. Everyone contributes, but leadership and vision are important -- we don't have the time or budget to create the vision as we go, so all of Appy's games have a single creative lead with a very specific vision for the game. The vision is always based around a single point of differentiation that fits with the Appy brand values of Personalization, Quality and Fun.

Prototypes: Each game is a series of prototypes until we have one we can ship. We try to get a mechanical prototype as humanly early as possible. Small amounts of pre-visualization - but only enough to serve as a guide for actual code.

Our projects vary depending on complexity; taking anywhere from two to five months or more and our team size averages between four and six people on a given project.

Sprints are either one week or two depending on the project and what "feels" right for the work. We generally have two releases: complete prototype and alpha game.

Sprints, Stories and task cards are used for the "development" phase of the project (2/3 length of the project). How the vision is implemented is left very loose and we are opportunistic about how we modify on the fly based around working gameplay and market conditions.

Time-boxing is critical and we have two values on every decision: Dollar cost and player benefit. It helps if it’s your own damn money at stake!

Lots of testing and watching people play. We are very informal at this stage in the company’s growth, so we’ll bring people in and have them play while we watch, then fill out specific questionnaires. We divide initial comments into three groups:
  • Must fix before release: these are usability and navigation issues primarily, though we have also added a last minute feature if it becomes painfully obvious that it would add a lot of player value to the app.
  • Add to our active update list: these are features or ideas that we like, but are not considered worthwhile enough to add to the 1.0 version by the game director. These are always the toughest ones, because our impulse is to always keep making the app better. But, you have to have the discipline to ship.
  • Add to the update backlog: these are features that we think have value, but we’re going to wait and see what the actual paying audience thinks before assigning them to a an update release.
The alpha/beta phase of the project is dominated by bug lists and daily prioritization. At this point, the product becomes highly "produced" and we have to choose the optimum amount of testing.

CK: What is challenging?

CU: Requiring everybody being in the building at the same time -- we have to outsource with contractors.

The iPhone user experience has to be simple. We have to fight complexity all the time. We have to remain focused and avoid “hobby horses” from design, code or art.

Focusing on scope and smart technical, gameplay and marketing trade-offs. This is the most critical aspect of our product development and requires the focus of the whole company. We need to be efficient, yet our business plan calls for us to create original games that are differentiated from the thousands of game apps in the marketplace, so there is always a tension between doing what we know how to do and biting off an experimental feature.

Our Executive Producer, Steve Sargent, assigns an exclamation mark to any feature, no matter how small, that we have not done before. These typically take us 2-3 times longer than the initial estimate as refinement and quality always take more time than initial proof of concept. By looking at the board filled with task cards with exclamation marks, we can get a real sense of the shipping risks of our projects.

CK: Tell us about your agile practices…for example, what is Appy’s “definition of done for sprints and releases”?

CU: "Done" varies, but for the most part, every sprint's work runs on the target platform. Releases are always pushed to everyone's iPhone for testing and evaluation over the weekend. We are informal at this stage. Done means "potentially shippable" and we don't move on to new functionality until the previous functionality is shippable. We strive to avoid at all costs the "parts on the garage floor", and would elect to ship "better with less".

CK: What are the things that surprise you in alpha/beta?

CU: Usually some of the final integration aspects (full audio, stress testing) will turn up some late issues. We are also surprised sometimes by miscommunications between contractors -- not a big or endemic problem, but it happens. We try real hard to identify mistakes as we go and not do them again.

CK: What "feels" the most different between iPhone and console development?  What is different about maintaining and communicating a vision?

CU: The platform and audience on the iPhone desire simplicity whereas on the console; technical and gamplay complexity are demanded by a more hard-core player (especially on the PS3 and Xbox). Right now, what constitutes a "genre" is still very much in flux on the iPhone and there are over a hundred thousand apps.

Development teams are much, much smaller and in Appy's case are integrated fully with the financial and marketing needs of the larger company. The vision of the game is communicated through a brutal process where we winnow down many ideas into one that the company is fully behind. That one idea is championed and led by a single person who has authority to be the final arbiter of trade-offs.

The visions are much smaller and more personal to the end user, usually built around a single mechanic.

From my point of view, having led both large console teams and iPhone teams, I spend almost NO time on "career coaching" or re-focusing individuals on the work at hand (which seemed to chew up a majority of my time with the larger teams), but instead spend the majority of my time solving problems, preparing the next game, working on marketing or working on Appy's strategic goals. I love working with my co-founders who are an incredibly creative and talented bunch and we are not big enough at this stage to have a lot of communication problems that can’t be solved by yelling at the guy sitting next to you or across the room.

About Chris Ulm:
Chris Ulm, CEO of Appy Entertainment: A “serial entrepreneur” addicted to building companies from scratch and guiding them to acquisition, Chris leads day-to-day operations, production, and creative development for Appy. An expert in building teams, Chris was essential in developing the creative teams and product development at High Moon Studios and was essential in High Moon Studios’ acquisition by Vivendi and later Activision-Blizzard, as well as the sale of Malibu Comics to industry-leader Marvel Comics.

About Appy Entertainment:
Appy’s first game, FaceFighter, was chosen by Apple as a “What’s Hot” pick and reached the status of “Top Ten Paid Game” in 5 of the 6 major markets worldwide. Their second game, Zombie Pizza was a “Top Ten Puzzle” game in the U.S. and was featured by Apple as a “Hot New Game,” a “New and Noteworthy” app and as a “Best Halloween Game.”  In addition, Zombie Pizza was featured in Entertainment Weekly magazine’s “Must List” and on the Huffington Post as a “Best Game for Halloween.” Tune Runner, their newest app, is a music-based action game that provides an interactive platform for players to use their iPods to discover and recommend songs to their friends

Appy's games have both earned "4.5 mice" from Macworld and Appy's apps have been downloaded well over one million times.


Great explanation of Scrumbut by Ken Schwaber.

Thanks to Attila Buturla for sending the link!

Sunday, January 10, 2010

Spouses, death-marches and Scrum

Another spouse led revolt about extended overtime (death-marches) has come out.  Invariably, some comments suggest that Scrum is a solution and the argument is led astray.  It's time to set some things straight.

Scrum is not a solution.  Teams and studios are the only solution to crunch.  Scrum is a not a methodology of "best practices" to solve problems, but a framework to create more transparency so  you apply common sense and find a ways to solve those problems yourself.

That said, Scrum and agile have tools and principles to help teams fins ways to eliminate death-marches:

Minimizing debt - Scrum practices focus teams on delivering features that demonstrate a level of quality and even optimization needed to determine their value and avoid excessive work or waste later on.  This doesn't mean that every feature developed every iteration is fully shippable.  It also means we avoid postponing as much debugging, polishing and optimization as makes sense.

Prioritizing scope - Features and requirements are developed primarily in the order of value they add and the risk they resolve (see below), not according to project management's resource allocation plan and schedule.  This way, if scope needs to be cut to meet a fixed schedule, it's not the highest valued scope.

Prioritizing risk - Uncertainty is not "planned away" in a document or schedule, but tackled head-on.  We don't build 20 levels without knowing they are fun and meet the budget (technical and production) constraints.  We shouldn't wait to see if online multiplayer works for our FPS until the end.

Manage by velocity, not what the plan says - Reality does not budge one inch for a plan.  Planning has to be ongoing and reflect the empirical measurements of team progress.  We can't "wish away" bad news or schedule crunch time to make up for a bad plan.  Contrary to some comments, knowing the original plan is not going to work sooner gives you more options than knowing it later.

These principles make looming death-marches visible far enough away to do something about it.  If this visibility is ignored, it can't be avoided.  Velocity demonstrates that extended overtime doesn't work anyways.

This is why it's said that Scrum merely creates transparency, but doesn't solve problems.  Creating transparency is half the battle.  Using it is the other half.


Scrum can help you keep your spouse happy, but don't take it too far.  I hear stories of developers teaching their spouses about Scrum and later finding a task-board and burn-down chart on the refrigerator with all their "honey-do" tasks identified and prioritized!

Thursday, January 07, 2010

ScrumMaster course for Game Developers before GDC

I'll be giving a Certified Scrum Master for Game Development course in San Francisco before GDC.

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 and follow-up test, 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 course is being held just prior to GDC on March 9th-10th at the downtown Marriott (adjacent to the convention center) The course has limited seating and is available for $1250 before February 1st and $1500 after, by registering here.

Discounts are available for groups of four or more.

More details for the course material can be found here.

Any questions? Contact me!

Tuesday, January 05, 2010

Introduction to Agile Game Development Webinar

Here is the one hour "Introduction to Agile Game Development" webinar of mine that the IGDA hosted last September: