Agile Game Development

Answering the right questions

2012-02-05T07:27:00.000-08:00

Someone recently asked how programmers and designers might communicate daily impediments if the programmers feel the designers either can't understand their impediments nor contribute to their solution.

Designers aren't usually going to jump in and suggest a code fix, but if the programmers feel that the impediments are mainly code issues, I sense another potential problem.

The greatest challenge in making games is "finding the fun": exploring mechanics and isolating the core gameplay that will draw players. This creates daily challenges of "how to get there". When the primary challenge becomes how to write the best architecture or how to create the most optimized physics, then the focus is on the plan, not the game.

David Jaffe said something during the last IGDA Leader Forum that stuck with me. He said that when developing Twisted Metal, they didn't create vehicle physics. They created a player object that acted like a hockey puck and then pasted some vehicle models in. Their focus was on creating the gameplay and let the player fill in the "fantasy of driving a vehicle".

Our arcade racing games always suffered from a tug-of-war between the vehicle simulation physics and gameplay. We should have let gameplay lead the vision. This doesn't mean that designers have the only important work. It means that every discipline is focused on delivering core value. Design asks the questions and the entire team seeks the answer….daily. Seeking those answers should create frequent, meaningful conversation. If it doesn't, I suspect the team is answering the wrong questions.

Why we should stop saying "vertical slices"

2011-11-29T07:30:00.001-08:00

The other day I came across the this blog post by Ron Gilbert called The Vertical Slice in which he rails against the creation of vertical slices. The following quote struck me:

"Vertical slices might work in a medium where you start at the beginning and grind though in a fairly linear fashion and what comes out is 90% complete. Maybe writing a novel works this way, but making movies and games do not. They are an iterative processes. You build foundations and the build up from there."

I love his image of the Mona Lisa's vertical slice. But Ron is using a different definition of vertical slice than I've always used. To me a vertical slice means is that we develop a feature to the point of knowing its value and use that knowledge to adjust the plan. The point being that the plan won't tell you how fun something is: the game will.

Ron's definition is that vertical slices emerge from a plan that defines all the slices up front. This might be a better approach from an engineering point of view over waterfall (fixing bugs along the way, etc), but it abandons the benefit of iterating on a plan with a working game. It doesn't surprise me that he's against that.

So maybe we should stop using this confusing phrase. Maybe we should call it a "game increment", or something. I'm open to suggestions.

By-the-way, here is how portraits were iterated on:

Do a Google image search on "unfinished portraits" and you'll see a lot of these, all with the heads nearly completed and little else in the portrait done. Can you guess why? It has something to do with prioritizing risk, and stakeholder value....things often spoken about in agile circles centuries after this was painted.

Also, da Vinci iterated on the Mona Lisa as well.

Announcement: Scrum Essentials Tutorial at GDC 2012

2011-11-23T08:27:00.001-08:00

I'll be giving a tutorial at GDC 2012 called "Scrum Essentials":

Attendees will learn about the full cycle of Scrum development, its principles and not the hype. They will leave knowing how Scrum works and will be able to begin its introduction at their studio and communicate expectations. They will be able to identify the patterns of successful and unsuccessful Scrum adoption, which Scrum practices should be changed to fit their game development process, and which practices should be preserved to achieve full benefits.

Rather than being a slide-driven lecture, the course will be focused on a combination of lecture, small group exercises and the simulation of Scrum by creating games throughout the day. You won't leave being experts on the rules and practices of Scrum, but thoroughly exposed to the principles of Scrum and the values of agile.

More on specialization

2011-11-01T08:26:00.000-07:00

My recent post on specialization has ignited a bit of argument with people on one side saying that I've "come out against learning" and specialists who didn't like my use of their UI/database specialties as a poor example (if I die in a suspicious UI/database related incident, my post is to blame).

The point of the post was that we should encourage "multi-learning" or more cross-specialization without seeking to homogenize all specialization. The point of the "anti-specialists" is that a graphics programmer should learn more about physics programming. There are benefits, personally and professionally, to doing this. There are common solutions in both and insights that crossing boundaries can create. I agree.

On the other side, many deep specializations take, as Malcolm Gladwell wrote, over 10,000 hours of practice and an innate skill to achieve mastery. I use the example of musicians because as a untalented amateur musician, there is no way I am going to become skilled enough to even write 10% of the music that a game needs. However, having worked side-by-side with them and learned their workflow, I can still help them do their job. Having learned about mixing and composition a bit, I have widened my world and appreciate game sound tracks a bit more.

We often specialize far too much. For example, some studios have specialized QA to the point where a programmer just has to hand off barely compiling code and someone else integrates it. QA should be the more the responsibility of everyone creating the game. Everyone on the team should care about quality. It shouldn't be a role.

We should also learn more about every surrounding role, every day. We each shouldn't be just a specialist cog in a development machine. We should be "game developers" first and [fill in the blank] specialists second. How many games have you seen or worked on where its apparent that one area of specialization dominated and ignored the rest of the game?

Scrum prohibits all specializations?

2011-10-22T09:54:00.001-07:00

A recent conversation about a team staying together long-term, etc prompted me to ask: "what if the team no longer needs a musician?" The responses stunned me. Some insisted that the role "musician" is not part of Scrum and that they are not part of the team. Everyone should learn to make music, write code, create art, etc.

Now, I understand that Scrum has been applied mainly to software products and that the elimination of "specialties" means that the database programmer, UI programmer and QA engineer should, ideally^[*], be able to perform each other's roles equally. This is valid. But the idea that that this extends to separate functions such as music, programming and drawing makes no sense.

In "The New New Product Development Game", the landmark 1986 Harvard Business Review article that first coined the word "Scrum" for product development, authors Takeuchi and Nonaka observed the benefit of cross-fertilization and multifunctional learning across specializations. These principles directly apply to mixed teams of artists, musicians, designers and engineers working together to create better solutions than using a "relay race" of handoffs. E.g. If I share a sprint goal with a musician, I become aware of their workflow and needs. I can help them solve a technical problem with the audio code and they can make the game sound great.

You can be sure that in my book and courses, I don't teach that functions should homogenize on a team. There is a role for a musician on a "Scrum team". It's called a "team member".

^[*] I've added the term "ideally" after posting this the first time. The reason for this "ideal" overlap of specialization is to promote multi-learning across all specialties. The goal is to have a shared understanding of each other's roles so that the team can continually improve how they work together but not to homogenize all specialization.

Homebrew build status traffic light

2011-09-24T09:40:00.000-07:00

Have you ever used build light indicator (a light, software utility or sound emitter) to inform the team about the current status of the build? Our team found using one of these, in conjunction with continuous integration and automated testing, to be a great help towards achieving 98% build stability. I have a little hobby/side-project going to build a better one starting with a $30 toy traffic light (see picture) and embedding some Arduino electronics that will allow it to be easily setup and used.

What the lights mean:

Green means the build is working
Red means that it is broken
Yellow means whatever you want. The server is building or a test has failed, but we're giving you X minutes to fix it before the status goes to red.

I'll open source the hardware and software. I might even sell a few at cost while I'm having fun making them.

Currently, the interface is an ethernet connection that uses DNS & DHCP to plug into your current network with little setup required. The traffic light will appear as a server that accepts simple commands that change its state. An optional audio cue will sound indicating a status change.

Potential future features:

Data logging the events and overall build stability metrics
Server page statistics (graph of stability, etc).
Simple display for setup options.

Please send suggestions about what you'd like such device like this to do and how you would like to interface it to your build server software.

Accountability vs. Responsibility

2011-09-03T07:49:00.001-07:00

[Cross-posted from Gamasutra]

I read this great quote from Gabe Newell in this Gamasutra article:
“Yeah, nobody can ever say "that's not my job." Nobody ever gets to let themselves off the hook. If there's a problem, you've gotta fix it.”

It demonstrates a high level of accountability at Valve, not just responsibility. The words accountability and responsibility are used interchangeably, but they don’t mean the same thing and the difference is important for game development teams.

Responsibility is assignable and forward looking. For example, as an artist, I might be responsible for creating a model. As a programmer, I might be responsible for making the character jump.

Accountability is backward looking. Both the artist and programmer should be accountable for the character correctly jumping over the model. Unfortunately, a lack of accountability might lead both to ignore the problem as “not their responsibility”.

Accountability isn’t as easily assignable as responsibility. It’s more intrinsic.

Focusing exclusively on the assignment of responsibility tends to tell developers that those making the assignments will take care of all the cracks that will happen between areas of responsibility. A balanced approached of delivering a part of a game and being accountable for its fun of it is harder.

The hard part is how is to grow accountability in a studio culture. How do you grow it in yours?

What makes a good “visionary”?

2011-08-19T13:01:00.000-07:00

[Cross-posted from Gamasutra]

There is a lot of talk about the visionary for a game, the person who creates and guide the vision through development. Who is the visionary and what do they need to do to make their vision come to life? I’ve been a project manager…not a product visionary, but I’ve worked with great visionaries and poor visionaries. These are my impressions and questions:

The role of a visionary on a creative project is an essential and demanding one. Many companies that consistently produce great products owe much of their success to their visionaries; Apple has Jobs, Pixar has Lasseter, Nintendo has Miyamoto, etc. But visionaries are nothing without talented teams to realize their vision. Vision needs to be communicated, reinforced, inspected and adapted to the emerging reality of the game. This is the visionary’s fundamental responsibility to the team.

A visionary must be demanding. They have to:

Unflinchingly question and test their vision early against the actual game.
Not allow work-in-progress (partially completed or unproven work) to drag out too long.
Call out substandard work immediately.
Ensure that the stakeholders are aware of progress and are able to safely air feedback.
Own a black turtleneck sweater

Successful visionaries have often been described as demanding, uncompromising, even brutal in their rejection of work that does not fulfill their vision. Lasseter resets movie projects late in development because the story or character aren’t right, Job's throws tantrums when a design isn’t intuitive and Miyamoto cancels games that don’t "find the fun fast". These are all examples of strong reactions to an emerging product that doesn’t live up to a vision. Does this mean that a visionary must be a tyrant? I hope not. There are as many different styles than there are personalities. The key, it seems, is to maintain integrity to a vision and to “course correct” towards the best game.

Good visionaries should be willing to compromise because no vision is perfect. Compromise is necessary to refine a game or to react to the unexpected, but compromise seems to go bad when the integrity of the vision is the thing being compromised: when the visionary assumes that some poor-performing part of the game "will be fixed later" or a bad mechanic "will be fun someday"; if the story-line isn't working, if the animation doesn't look right or if the system is sluggish, the visionary must demand correction. However, when the visionary is afraid to hurt the team's feelings or needs to hit an arbitrary milestone date, then the wrong game is created and the team must eventually face the mad scramble to cobble something together when time runs out and a vision is sacrificed for a ship date.

Things we know:

Black turtleneck sweaters aren’t enough.
Methodology can’t automate the role. Games will never come from an assembly line.
Vision, alignment, talent and leadership are all necessary elements of any great game and can’t be separated.

Questions:

Do visionaries have to be mentors? Some of the best visionaries work with creators to demonstrate how to best work. I’ve read about Lasseter sitting down with individual animators to teach them how to animate the eyes of a particular character. Not all visionaries do this though.
Do visionaries need a big job title? It would seem they do in most cases, but it is it absolutely necessary?
How thin should they be spread? Can vision be taught? Pixar production is limited to how many visionaries they have working for them. Brad Bird couldn’t even take a few days of vacation before he was recalled to head up Ratatouille. Steve Jobs’ illness has everyone wondering whether Apple will tumble when he leaves.
How does a studio identify and handle a poor visionary? It’s easy to promote the wrong person to the visionary role, but hard to remove them. A bad vision will kill a game or even a studio. A bad visionary will blame the team and not the vision.

Next Certified "ScrumMaster for Video Game Development" course

2011-08-03T17:34:00.000-07:00

Announcing a two day Certified ScrumMaster for Video Game Development course in Los Angeles on October 24th-25th at the Sheraton LAX, just before the IGDA Leadership Forum at the same location. Plus attendees of this course will receive free admission to the Agile Game Development Gathering on October 26th.

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.

More information about the course is here.
Register here.

Agile Game Development Gathering!

2011-08-03T17:06:00.000-07:00

On Wednesday, October 26th, the IGDA will be hosting the first agile game development gathering at the Sheraton Gateway Hotel, LAX, the day before the start of the IGDA Leadership Forum. The gathering will bring together game developers who have been applying agile and lean practices (including Scrum, Kanban and XP) to share their successes and failures of applying agile to their projects and advance the art of agile game development. Rather than a series of presentations, the gathering will use Open Space Technology to support a self-organizing agenda.

Discussions will be driven by participants during the gathering and will include topics such as:

Helping teams take more ownership
Creating and managing a great product backlog
Best practices for mobile, flash, social, MMO and AAA game development
The role of producers on an agile team
Long-term project management
The role of QA in Scrum
Practices in production vs. pre-production
When to use Scrum, when to use Kanban
Failure stories. Things to avoid
How can publishers work with agile developers
Culture wars. What are the challenges to becoming agile at your studio
ScrumMaster tricks and tips
The role of artists and designers in Scrum. What works best?
Product owner success and failures
Establishing a "definition of done"
Tools: What tools work and don't work. How should they be used?

Registration costs $149 here.

E3 and agility

2011-06-06T12:31:00.000-07:00

Ah E3. I haven't been to E3 since 2006, after which it was downsized due to how bloated and expensive it had become. I had attended every since it started in 1995, during the exciting early days of 3D hardware, through its steamy times in Atlanta and then back to Los Angeles, where it continued to grow beyond reason.

E3 was always preceded by a time of focused crunch: trying to make a box of gameplay parts come together into a working, fun game, followed by days of overwhelming noise, nights of excess and then a period of recovery, where we tore out all the bailing wire and duct tape that held the game together.

There were a lot of bad things about preparing for E3, but the best thing about it was that your game had to demonstrate fun to potential customers. It was a time when the entire team focused on making the game fun, rather than keeping up with a schedule for its own sake.

I always felt that we needed more E3-like goals, but without the crunch, hacks and recovery.

Then I learned about Scrum and the sprint goal: to demonstrate a game that's more fun than the one shown from the previous sprint. This sounded like having an E3-like build every 2-3 weeks without all the bad parts. However, this isn't always the case for Scrum teams. There are a couple of main reasons they use to explain why:

"It takes too long to create a stable build that runs at decent frame rates"

Very often, teams that start Scrum have an existing process that requires weeks of time to lock-down new feature additions and apply testing and optimization to achieve a playable build. Scrum puts pressure on them to find ways of reducing this overhead. It can take months or years, but eventually better practices and automation help the team keep the build stable and optimized enough to demonstrate value every sprint.

"It's impossible to always show improved value every sprint. Sometimes it takes months for all the parts to come together to make a better game"

This is true. Often it takes multiple sprints to demonstrate playable value on core mechanics with decent assets (i.e. running around shooting capsules in a flat shaded Lego block style environment isn't a lot of fun). However, many times this attitude is taken too far. As a result, releases become a series of fragmented sprints, which produce parts that are integrated at the end and the fun only emerges once every three months:

There are a few main problems with this:

Late integration often shows that some design assumptions were incorrect, but the team is out of time and can't revisit them.
The team often lacks a shared vision of what they are building during the release. They focus more on completing tasks than adding fun.
The end of the release starts to look like the weeks leading up to E3: Lots of crunching and hacking just to "get the build working".

Scrum teams (including the ScrumMaster and Product Owner) should continuously push to shrink this once-a-release play and adapt cycle. If they do, then sprints and integrations during the release will start to look more like this:

Eliminating TPS Cover Sheets

In fact, this cycle should never be short enough for a Scrum team. This is not to say that this will eventually lead to the game being improved every hour of every day. This attitude continuously influences the team to eliminate artificial process barriers (such as excessive baking time, long build practices, etc): all those expenditures of time and effort that are not spent directly improving the game.

E3 goggles

Producing an "E3 ready" build every sprint might not always be possible. Tying up all the loose ends --making sure the build runs as long as possible on the target platform--takes a lot of effort, but teams should explore ways to find fun, build knowledge, reduce risk, refine cost projections every sprint. We benefit from looking at the game through "E3 goggles" more often, which lets us look at the game from the point of view of E3 attendees.

Team motivation and the role of the ScrumMaster

2011-03-07T15:12:00.000-08:00

Before reading this article, watch this 20 minute presentation by Dan Pink at TED (if you haven't already):

Take-away: Motivated teams perform FAR better than unmotivated one and creative workers respond best to intrinsic motivation.

Research has shown that the following three factors influence intrinsic motivation the most:

Autonomy - The urge to direct our own lives
Mastery - The desire to get better at something that matters
Purpose - The yearning to do what we do in service of something larger than ourselves

We want motivated teams. We want to be on motivated teams. We want to be motivated ourselves.

Motivation and the daily stand-up meeting

The daily stand-up is a window into the motivation level of the team. Stand-ups with motivated teams are noisy, complex, often chaotic, and information rich. They often seem like football huddles when the score is tied and there are no timeouts left in the final two minutes of the game. There is humor, intensity and a sense of "being in it together".

The stand-up meeting for an unmotivated team is different. It's common to sense the boredom or an impatience for it to end. It often feels like a group of individuals reporting to the ScrumMaster, who is writing everything down, or even worse, with everyone sitting at a conference table looking at a projection of a spreadsheet on a wall and only paying attention when it's their turn to report.

A tedious daily stand-up meeting is a symptom that the team lacks one or more of the factors of intrinsic motivation. It's often easiest to examine the team's autonomy and the practices of the ScrumMaster, whose role is to foster and grow autonomy.

Old dog, new tricks.

Often, ScrumMasters are recruited from the ranks of management. They have years of experience managing people by creating estimates, assigning resources and tracking progress daily. Scrum is meant to shift these responsibilities to the team. The practices for doing this are simple but, like learning chess, the mastery of them takes time. A common barrier is that the manager doesn't know how to trust the team and the team doesn't trust management's motivation. This cultural clash was captured in a mockumentary we made years ago at High Moon:

Often new ScrumMasters think their job is to manage details for the team and let them focus on their coding, asset creation or tuning tasks. However, we all know that plans are fuzzy. Even a two-week plan to create something compelling won't cover every conceivable bit of work (e.g. how many hours of tuning do you plan to make sure a mechanic "feels right"?) . We need everyone on the team thinking about and examining what they are doing on a daily basis, not just following the plan made at the start of the sprint. A sense of ownership, even for a mere two weeks, greatly benefits the goal.

Emboldening the team to take ownership

Teams rarely take ownership at the start of a Scrum adoption and management rarely hands it out. It takes time for roles, practices and trust to shift. It's the ScrumMaster's role to insure that this shift occurs and that the inevitable collisions with studio culture are managed.

This includes emboldening the team to accept the risk of occasionally taking on too much and seeing their goal as primarily one of adding value, not simply reducing all their task times to zero. Discovery and innovation are fueled by passion and motivation, but these both increase risk. Playing it safe, padding out tasks so they are never late, or punishing teams whenever they challenge themselves too much kills motivation, and therefore innovation, fast.

A ScrumMaster is like a parent, in this regard. All parents have some apprehension when their toddlers are ready to take their first step. They pad every hard edge in an enclosed area and try to make it as safe as possible for their child to learn to walk, but parents have to let go at a certain point and let the risk of a bump or bruise outweigh their desire to protect their child from every possible mishap. Growth is necessary. Soon enough, the padding and gates are taken down and we marvel in pride that our children are strolling up and down the stairs we once considered life-threatening!

Similarly a ScrumMaster emboldens the team to take more ownership, but creates an environment where it's safe to fail (yet desirable not to). They shift layers of management responsibility to the team, always with the goal of coaching the team to higher levels of autonomy, which leads to more motivation, greater performance and, as a result, a better working experience.

Design as questions, development as answers

2011-01-27T14:33:00.000-08:00

In Scrum workshops, I often ask developers if they have ever compared the game that they last shipped against the original design document. The usual answer is that, except for the title, much of the design changed during development.

We are all accustomed to the idea that design documentation is a starting place or a way to win over the stakeholders, but they are poor maps for development. The problem is that, lacking a better map, we set off on a development journey that is often longer than planned or takes us to places we didn't want to go.

Studies have shown that excessive documented specifications can create a false sense of certainty and lead teams astray. A better approach is to is to acknowledge that designs are speculative and need to be proven out.

Other industries have faced this problem long before us. Take, for example, the Boeing 777, the largest twin engine plane built, that revolutionized airplane development and production at Boeing (it was the first airliner fully developed on computers).

One of the many innovations in the development of the plane was to create more concurrency between design and manufacturing (see concurrent engineering). Before, manufacturing had to wait for all the designs to be complete before they started. In traditional airplane development, designs are done years in advance of metal bending. Often a problem with design wouldn't be detected until lots of metal was bent and subsequently had to be scrapped, costing millions. This problem should sound familiar to game developers!

To address this classic problem, the 777 program integrated manufacturing closely with design. Before the 777 there were only two states for a drawing: released and unreleased. It was either completely done or not at all. What they did was add states in between. Each of these states had to correspond to levels of manufacturing release before they could move the next drawing state. This reduced the amount of uncertainty that existed with a design going in steps; catching problems and introducing improvements far earlier. This maximized performance with design and manufacturing and contributed to the 777 being developed in record time.

For games, big designs up front (BDUFs) have a similar problem. A design is either implemented or not, and most of the key design decisions are made without all the information. We often discover, in production, that we've overlooked some key technical issue that won't allow a feature design to be realized as we had hoped. We waste effort, throwing assets away and rewriting code to "make it work".

Can we do something similar to Boeing? Yes. As discussed earlier, we need to explore our designs and seek out what works and what fails. Rather than introducing a fixed number of stages in our design, design should introduce questions for core features than then must be answered by development before we move on.

What are some of the questions about core features:

Is it something we want?
Is it fun?
Where is it used?
What are the technical risks?
What is it's development cost?
What does it cost in production?

When a design document is written, we don't know the answer to most of these questions, but the true answers that emerge have scuttled many schedules and budgets. The start of a project is the worst time to try to answer such questions because that is when we know the least!

Take for example, "fully destructible environments". How many times have we seen this feature in games that don't live up to its promise? As a developer on a project with this feature goal, my experience was that the surprising amount of production time this feature added ended up killing it and wasted all the development effort we spent in pre-production. We should have explored the question of production cost well before production started.

Much of development is investing in gaining knowledge about what to build and so making the most of development effort is about gaining the right knowledge, or, asking the right questions. In the context of Scrum, these questions lead to the priority of items on the backlog, the order of work done in a release and a specific goal for each sprint.

Agile Game Development - An introduction

2011-01-25T10:18:00.000-08:00

A one-hour introduction webinar to using agile for game development. The PDF version of the slides are here and the Powerpoint source for them are here.

Justifying Research Teams (or not)

2011-01-23T12:04:00.000-08:00

Have you ever been on a project that was significantly delayed because the new technology or gameplay took longer than expected? Many of us have, and it should come as no surprise that new tech, mechanics or complex, exploratory asset creation schedules are hard to predict. Yet they are part of projects with tight delivery dates.

These elements are often seen as the "critical path" of a project, which means that if they are delayed, the whole project is delayed. Competent management of projects includes identifying such critical paths and prioritizing the work on them.

However, if there are many possible solutions and therefore a lot of uncertainty along a critical path, or if a number of projects share the same solution, the risk is often very high.

A common way to address this is to have a separate research team explore a solution well ahead of the start of a project or at least the point where the path becomes critical. There are some advantages of this. The first is that these research teams can have the time or resources to fully explore solutions and pick one that is best for the product and is not rushed into production due to schedule pressures.

My favorite example of this is the Toyota Prius' development. Toyota's goal was to create a car that would appeal to the "green" consumers. However, the choice of engine technology was not certain. Either a hyper-efficient gas engine, an electric engine or a hybrid were all candidates. Delivering the car to market in half the time that a typical car was developed was the challenging goal. It was their critical path.

Toyota could have chosen an engine technology up front and focused their efforts on making it work. Most companies, faced with this tight schedule, would have done so. Instead what Toyota did was inaugurate three research teams to study each engine technology.

Months later, the all-gas engine team found that although they could improve the efficiency of the engine, they couldn't deliver enough efficiency to attract the green market. The electric engine team found that they could achieve the efficiency, but they couldn't deliver a car with a low enough price to entice buyers. Although people want to be green, there is a limit to how much they will spend.

The hybrid engine team were able to build an engine within the mileage and cost targets, and it was chosen and refined for production.

When hearing this story, many managers are unmoved. "We can't afford to have multiple teams researching multiple solutions!" they say. In response, we might ask "how much does it cost to delay the entire project by months because the critical path was stretched out?" You can easily spend 10 times the cost on a delay for a 80+ person team than you would have been researching up front with a much smaller one.

The concern about cost is not the only barrier to such teams. There are at least three others:

Proper focus - Insuring that the team is working, in a very focused way, on the right thing and not just an interesting project that will not directly benefit products.
Raiding - Guess what happens when a project runs into trouble and wants to add bodies (often a bad idea in itself). They raid the research team!
Transferring the solution. How does the project adopt the solution?

Each problem has a solution that is unique to a company, but often the best solution to the last problem is to have the researchers join the project until the new solution is in place and the project team can take it over.

Research teams are not always the answer. There are pros and cons to having them. If uncertainty is low, it's often better to have research be part of the project. You have to judge how much uncertainty you have on your critical path and therefore how much you are willing to gamble on a delivery date.

Certified ScrumMaster for Game Development at GDC 2011

2011-01-18T10:58:00.000-08:00

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 February 28th-March 1st 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!

Valuable failure

2011-01-15T09:24:00.000-08:00

When exploring a new design, we want to generate information about its value. Is a design element going to add to the product? Is it going to be something the customer wants? Is its cost offset by a greater value? All of these are uncertain until we try it.

Uncertainty points to a lack of information. As a result, the work we do should focus on generating the highest quality information possible. This isn't done in many cases. What is done is that we focus on avoiding failure and in doing that, we limit the information generated.

Take a simple example of the high/low game where one person has to guess a number, say between 1 and 100, and the other person, who knows the number, tells them if each guess is too high or too low. What is the first number guessed by the "expert" high/low player? It's 50. Every time. Do they expect to pick the right number the first time? No. So why pick 50? As it turns out, guessing 50 generates the highest quality information. Picking 90 on the first guess would have an equal probability of success or failure, but it generates far less information than guessing 50.

Not all designs ideas are as uncertain as picking a number between 1 and 100, but there is always uncertainty. Often however, we create goals that ignore the uncertainty and try to prove the first guess as correct and as a result generate less information. This is usually because our work cultures reward correct guesses and punish incorrect ones.

A better approach is to welcome information-generating failure as much as success.

(read about organizational design and risk management in "Managing the Design Factory", by Donald Reinertsen)

Tools quote

2010-12-31T08:11:00.001-08:00

From Don Reinertsen's "Managing the Design Factory":

"We must continue to think about what we are doing and avoid value-laden labels that oversimplify decisions. It is for this reason that this book focuses on tools rather than rules and rituals. A tool enhances our ability to achieve a certain effect in a certain contact. A hammer is good for sinking nails but a poor way to drive screws".

Tips for Effective Daily Stand-up Meetings

2010-11-22T09:44:00.000-08:00

When visiting a studio, I'll often ask to observe the daily stand-ups meetings. It's the best way to sense where a team is and how to focus coaching time for the visit. An effective daily stand-up meeting is an energetic swarm of committed team members that need to quickly synchronize their efforts and identify anything that is threatening their shared goal.

Some daily stand-ups (or daily scrums), aren't like this. They are monotonous, manager-led and pointless to the attendees. Teams here lack any sense of commitment or ownership and they eventually question the merit of the practice and perhaps even abandon it. Unfortunately, abandoning the stand-up doesn't improve their chances of building commitment or ownership, which are principles of Scrum. So I've compiled a list of pointers on ways to improve the daily stand-up meeting and improve commitment and ownership.

The stand-up is for the team. This meeting is for the team to synchronize their efforts towards achieving their goal, not just as a status report. If their are any "management artifacts" that need to be created (such as an update to a tracking tool), it should be done outside the meeting.

The rules aren't fixed. The "answer the three questions" rule you read about in books is only the starting place. Teams add questions, change the format, and do anything necessary to address their needs.

It's about the commitment to the goal, not just the tasks. Task tracking is critical, but work will arise on a daily basis that wasn't considered during sprint planning. Teams need to react to this new work and balance it daily against their goal. They need to inform each other about new developments and threats to their goal. They should care about accomplishing the tasks, but they should care about the goal more.

The ScrumMaster must know their role. ScrumMasters do not run the daily stand-up. They facilitate them. The difference is that the rules for the stand-up come from the team and the ScrumMaster ensures that those rules are followed. If the team has decided that being late to the stand-up is not acceptable, they'll likely have a rule in place to chastise those who are late. Paying $1 or singing a song is common. ScrumMasters must not let them off the hook.

It's a "stand-up" meeting. If you took the same meeting and had everyone sit down, its duration would increase by 50%. Standing creates a sense of urgency. Try making another meeting "standing only" and see what happens!

Respect the time-box. Some of the most effective stand-ups I've seen were five-minute "hurricanes of energy and activity". The team shared what they needed to share and went back to work. Stand-ups that take longer than 15 minutes are just wrong and need to be fixed.

Prefer a physical task board. This is not always possible to have, but here is no electronic replacement that is equivalent. A physical task board with cards allows everyone on the team to handle the tasks simultaneously at the same location. It encourages team ownership.

Avoid projectors. This might seem a bit redundant given the last point, but projectors used in a stand-up meeting should be renamed "conversation killers". Projectors usually involve a software tool that provides information in a linear, one-at-a-time way with someone, unfortunately often the ScrumMaster, at the keyboard/mouse controls. If defeats the non-linear, swarming-on-the-goal, value of the stand-up. Software tools are often a critical part of project planning and tracking, but they have no place in a co-located daily stand-up.

Prefer stand-ups in the team workspace. The ideal stand-ups are around a task board in the team's working area. It reduces the amount of time walking to a war room and allows the team to have the task board near them all day. This is not possible with distributed teams, but helps collocated ones.

It's owned by the team. The team picks the format and time of day of the daily stand-up. Since they own it, it should run the same way, regardless of whether the ScrumMaster is there or not. One simple test I recommend to ScrumMasters is to occasionally hide around the time of the daily scrum and see what happens. If the team meets and runs the stand-up the same way as when you are their, you are doing a good job. If they don't meet or stand around wondering what to do, they have some things to fix.

No more play-doh

2010-11-12T11:38:00.000-08:00

My courses and workshops, use exercises, discussions and simulations to help attendees embrace the principles of Scrum and Kanban. The simulations are among the most challenging to create. Finding the best way to--for example--simulate a sprint in 15 minutes to creative game developers is not easy. So I try variations of games other trainers use and invent some of my own.

Over the past six months, one simulation I've used is called Movements of a Hypnotic Nature (see slide 14 for more details). Good things were said about it, so I tried it. The simulation requires play-doh, golf balls, string, straws, etc: lots of interesting things used to build a simple product that moves and has an aesthetic quality.

There were two problems with this simulation. The first is that the connection between the simulation and Scrum can be a bit nebulous. It's not a bad simulation, but I've found better ones (e.g. some based on Legos). The second is traveling with all this stuff. It adds a lot of weight and recently when I was packing, I noticed that the pay-doh, timers (used for time-boxing the simulation) and wires for all the gadgets I carry happened to pile-up in a disturbing configuration:

Airline security is enough of a hassle right now without this being seen by a baggage inspector. Sorry future workshop attendees, but play-doh based Scrum simulations are now off the menu!

The manifesto for agile game development

2010-09-21T08:50:00.000-07:00

The Agile Manifesto contains four values and twelve principles for "Agile Software Development". It's simple yet powerful and still applies nearly 10 years later.

I've modified them slightly to better fit game development.
----
We are uncovering better ways of developing games by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over process and tools
Working game over comprehensive design documentation
Publisher collaboration over milestone negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The principles behind the Agile Manifesto:

Highest priority is to satisfy the customer through early & continuous delivery of valuable software, assets and gameplay.
Welcome changing requirements, even late in development. Agile processes harness change for the developer's competitive advantage.
Deliver working gameplay frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people & developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient & effective way of conveying info within a dev team is face-to-face conversation.
A working game is the primary measure of progress.
Agile processes promote sustainable development. The sponsors and developers should be able to maintain a constant pace indefinitely.
Continuous attention to balanced artistic quality, technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done—is essential.
The best architectures, budgets, assets, requirements, and designs emerge from self organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Success with Agile Managers

2010-09-09T09:57:00.000-07:00

The studios I visit that have the most success employing agile have something in common. There is often a champion of the effort to become more agile who has a position of authority there.

Some of the things I have noticed about them are:

They understand the principles of agile and Scrum. They understand the source of change comes from the teams, not a process.
They care about their people. They want to see an end to the cycles of project madness.
They are willing to grow trust with the teams.

Although this role isn't defined as part of an agile process, it is often is a valued one. Lately I came across the description of a role called the "Agile Manager" in a great book by Lyssa Adkins called "Coaching Agile Teams". In the book, she writes that an agile manager's role is:

"Organizational change artist: Guides the organization through agile adoption (and re-adoption).
Boundary keeper: Reinforces healthy role boundaries both within the team and between the team and the greater organization.
Value maximizer: Manages the portfolio of projects like a product owner manages a portfolio of user stories, always asking what the highest business value project is now.
Lean manager: Uses lean thinking to improve organizational flow so that the value teams deliver can be realized without delay.
Organizational impediment remover: Finds the gritty courage it takes to remove entrenched impediments.
Team champion: Offers observations from the team boundary and releases the team to reach their fullest potential by truly believing they can.

The agile manager is like water--patiently, water can carve away the hardest surface, and it will always find a way to flow. Making things flow so the team delivers again and again is an honorable (and challenging) job. In so doing, agile managers offer their highest service to the team. "

While this role isn't unconditionally necessary for success in all cases, it is for teams that don't have the authority to overcome organizational inertia that can prevent a team from becoming agile.

Agile Development in Practice at Epic Games

2010-09-09T08:29:00.000-07:00

Someone posted the slide deck from Epic's presentation made at a GDC tutorial a few years back. It's brief, but it was a good presentation.

Great product owners don't count on miracles

2010-09-07T08:59:00.000-07:00

As a CTO or Director of a game studio, one of my principles was to hire the best people possible (the most talented and committed) and trust them to do their job.

This always got the job done, but at a cost. Those talented people showed their commitment by working grueling long hours and wasting weeks of effort. I'd given them plenty of rope to hang themselves from and they used it. I expected miracles as part of planning process.

When we started using Scrum, one of the biggest challenges was the product owner role. Casting an existing role, like a lead designer, into it wasn't enough. The transition of thought, from executing on a detailed plan, to iterating with a critical eye on emergent value, doesn't happen overnight.

At first, we iterated on a fixed and detailed plan. This led to a phenomenon, described in my book, (chapter 12, Agile Design) called "parts on the garage floor". In doing this, we produced separate polished parts of a mechanic. However, the value of the mechanic didn't prove itself until all those parts were integrated together in a production level and demonstrated. By the time this happened, if the value emerging wasn't good enough, it was too late to do anything about it.

The art of great product ownership requires a different mindset:

Product owners have to trust the team to do miraculous things within a sprint, but not count on miracles beyond that.
Product owners should not fall in love with their vision. The must take the truth from the working game and use it to "true up" their vision.
Product owners should demand value be added every sprint.
Product owners must be honest and transparent with the team. Even when it hurts.
Product owners must take council from their domain experts and prioritize based on cost and risk as well as value.

The last point was crucial to my role as the CTO-who-depended-on-miracles. Although I couldn't create these miracles, I certainly could foresee where they were needed. I knew where the risks usually lay (when you are burned enough times, you eventually figure out that fire is hot). The knowledge of risk was applied to the order of the backlog. For example if porting our engine to the next generation platform is a major risk, we should do something about it earlier than later. Then we won't need the miracle.

It's important for the product owner to understand risk and use it to prioritize the backlog. They are responsible for the direction of the project outside the sprints. They have their hands on the steering wheel of the project and need to steer it in the right direction.

An iterative and incremental scale graph

2010-09-06T09:49:00.000-07:00

The phrase "iterative and incremental" development is tossed around quite a bit without much distinction between the two. The distinction is important for large-scale games (the kind shipped on discs). In talks over the past few years I've shown a table that compares the differences, but on a recent flight I came up with a more graphical way to express the differences.

For such large games, there are usuall several phases of development that can't be blended perfectly even under an agile framework. Theses are:

Concept - Ideas are considered, prototyped, and thrown out quickly.
Pre-production - Ideas, winnowed through the concept phase, are built upon and refined.
Production - Multiple levels, characters and other assets are mass-produced based on what was discovered in pre-production.

In an ideal agile project, all of these activities are mixed equally. For such games, this proves to be impractical. For example, if you change the jump height of the player on a platformer in the middle of level production, you may need to redo hundreds of ledges that baked in that height. An "agilist" would recommend that you make all your ledges procedural so that you can continue to tune them, but this is often not a practical or cost effective solution. We have to make decisions before production starts.

So here is the graph I jotted down (I love Omnisketch on the iPad):

What this communicates is the flow of development (the green line) from concept, through pre-production into production. This flow can be for the entire game or a class of assets (such as levels). The goals for the team and stakeholders moves from "correctness" (making the right game or asset) to that of "efficiency" (making it as low cost as possible). Each goal guides how we do the work, either using spikes in concept development, Scrum in pre-production, or mixing in lean practices such as kanban in production.

The blue box in the lower left represents "total certainly" in our requirements and technology, which is fine if your mass-producing widgets, but is never a state we're in making games.

I find this useful in explaining that the work chooses the methods, not the other way around.